¿Qué es la arquitectura?
La RAE define la arquitectura como:
1. f. Arte de proyectar y construir edificios.
2. f. Diseño de una construcción.
Aplicándolo al mundo del desarrollo de software podríamos redefinir arquitectura del software como:
1. f. Arte de proyectar y construir aplicaciones informáticas.
2. f. Diseño de una aplicación informática.
La definición que le damos a arquitectura viene del mundo de la construcción pero viene a significar lo mismo en nuestro mundo, solo que nosotros no construimos edificios, construimos software.
Una arquitectura define la forma de trabajar en un sistema, como construir nuevos módulos, pero también debe dejar intuir el tipo de aplicación que describe. Tal como comenta Uncle Bob, si mostráramos un dibujo arquitectónico de una iglesia o de un piso, simplemente con ver la forma que tiene ese dibujo podemos intuir que tipo de edificio está proyectando. Así pues, si observamos nuestro dibujo arquitectónico de software deberíamos de poder intuir qué tipo de aplicación va a ser construida. No es lo mismo una aplicación que controla un hospital que una aplicación de un cajero automático, cada una tendría un dibujo arquitectónico distinto.
Sin embargo, el dibujo arquitectónico en la construcción no deja claro los materiales con los que está hecha, así mismo en el dibujo arquitectónico de nuestro sistema no deberíamos dejar escapar detalles de nuestra implementación.
Así pues, considero el dibujo arquitectonico en un proyecto de software la propia estructura de modulos y carpetas o paquetes en el caso de Java o cualquier añadido que ayude a expresar la intención de nuestro sistema sin expresar el cómo está hecha.
Uncle Bob además define una serie de “arquitecturas limpias” que tienen una serie de objetivos en común:
1. Independiente de los frameworks. La existencia de esta forma de construir cosas en el sistema no depende de un framework.
2. Testable. Tu arquitectura hace que tu código pueda ser testado.
3. Independiente de la UI. Tus reglas de negocio no se ven alteradas por un requerimiento de UI, cuando desarrollas una funcionalidad nueva es la UI la que se adapta a tus reglas de negocio y nunca al revés.
4. Independiente de la base de datos. Puedes cambiar el motor de persistencia ya que tus reglas de negocio no son dependientes de la implementación concreta de la base de datos sino que es la base de datos la que se adapta a estas reglas.
5. Independiente de cualquier componente externo. Se aplica la misma regla descrita en la base de datos pero relacionada a componentes externos así como integraciones con otros sistemas, librerías, etc…
Si una arquitectura cumple estos objetivos podría entrar en el grupo de arquitecturas limpias.
Casos de uso
Un caso de uso es una acción que un usuario o agente externo realiza en nuestro sistema. Se nombran siempre con un verbo + nombre. Si estuviéramos desarrollando una aplicación en la que se venden productos, ListarProductos sería un nombre válido así como ComprarProducto.
Una manera común de identificar la intención de nuestro sistema es modelarlo en base a sus casos de uso. Son la forma de acceder a las reglas de negocio de nuestra aplicación, por lo tanto podríamos decir que representan la parte pública del dominio de nuestra aplicación. Al ser la parte pública hacen de entrada/salida de datos al dominio.
Los casos de uso nos ayudan a expresar con un lenguaje más natural las acciones posibles que nuestro sistema puede realizar y de esa forma listan las funcionalidades del mismo. Un listado de los casos de uso ordenados por funcionalidad nos ayudará a saber de qué trata la aplicación con la que estamos trabajando. Por ejemplo, en Java, si distribuimos los casos de uso separados por paquete de funcionalidad, nos dará esa visión de dibujo arquitectónico de la que hablábamos al inicio del post.
Para hacer la acción hablarán con elementos internos de nuestro dominio tales como servicios u objetos de modelo ricos para que mediante la colaboración de los mismos resuelvan la acción.
Estos casos de uso son pues el elemento de entrada de nuestra aplicación y controlan la secuencia de pasos de los elementos internos con los que colaboran. Para resolver un caso de uso como ComprarProducto quizá en nuestro sistema los datos de entrada tengan que pasar por un objeto validador y en el caso de que los datos sean válidos guardar ese objeto en persistencia, por lo que esos dos pasos estarían correlados en el caso de uso.
Reglas de negocio
Una regla de negocio es un requerimiento del encargado en definir cómo funciona una aplicación, en Agile usamos el rol de Product owner. Definen el comportamiento de nuestro sistema y cómo reacciona a las acciones por parte de un usuario o un agente externo si tuviera que interactuar con otros sistemas. Las reglas de negocio aportan valor al sistema que estamos construyendo.
Como hemos descrito hasta ahora nuestras reglas de negocio son el núcleo de nuestra arquitectura, todo depende de estas reglas, ya que al fin y al cabo creamos software para ofrecer una solución a una una necesidad.
¿Por qué es tan importante separar nuestras reglas de negocio? El software evoluciona, los frameworks, base de datos, librerías que usamos son solo herramientas con las que construimos un sistema, pero tal como van evolucionando, la forma de usarlas cambia o incluso son reemplazadas por unas mejores, será mucho más fácil reemplazar estas nuevas herramientas en nuestro sistema si están lo más aisladas posible.
Existe una única regla para usar una arquitectura limpia, la regla de dependencias. Esta regla expresa que la dependencia entre componentes de nuestro sistema debe de ser desde los detalles de implementación a nuestro dominio y nunca dejar que nuestro dominio conozca estos detalles. Esta es la herramienta que tenemos para aislar lo que realmente aporta valor a nuestra aplicación de la implementación o tecnologías que usamos.
Pero tu Product Owner difícilmente te va a explicar exactamente las reglas de su negocio, seguramente exprese lo que espera encontrar o cómo va a reaccionar la aplicación en determinado caso, somos nosotros los desarrolladores los encargados de traducir su lenguaje y extraer las reglas de negocio y modelar la aplicación en base a lo que llamamos un modelo de datos de dominio, siendo el dominio el negocio del que estamos hablando.
Este arte de transformar una especificación en algo tangible en el desarrollo del sistema es difícil y no tienes que preocuparte de que no sea perfecto en un primer momento ya que es algo que debería estar en continua evolución según se va ganando conocimiento sobre el dominio, a esto lo llamamos refinamiento continuo.
Para hacer este refinamiento continuo tenemos que cambiar partes de nuestro sistema para que reflejen claramente la intención. Un libro que te puede ayudar mucho a entender mejor el modelado del dominio de una aplicación y enseña ciertos “patrones” de como modelar objetos de dominio es Domain Driven Design de Eric Evans. Un libro que cualquier desarrollador debería leer.
Si cambiamos partes de nuestro sistema, deberíamos tener la seguridad de que estamos haciendo cambios sin dañar otras, para eso necesitamos que nuestra arquitectura sea testable.
Testing
Toda esta separación entre reglas de negocio y el resto de partes de nuestro sistema hacen que nuestros componentes sean testables ya que comunicamos las piezas que componen este puzzle con abstracciones. Las abstracciones son nuestros aliados a la hora de componer estas piezas ya que nos proporcionan 2 claras ventajas: dar significado semántico a los colaboradores de una clase e invertir la dependencia para poder mockear un colaborador en test.
Esta inversión de dependencias nos permite también cambiar el detalle de implementación de una clase lo que hace que nuestra arquitectura sea independiente de las herramientas que mencionábamos previamente ya que hay que distinguir entre el qué hacer (abstracción) y el cómo hacerlo (implementación).
Independiente de agentes externos
Nuestra aplicación, como hemos comentado, debe ser independiente de agentes externos tales como frameworks, bases de datos, UI, APIs externas u otros sistemas que no tenemos control. Para cumplir con esta regla debemos tener claro que cualquier agente externo puede ser dañino, ya que en cualquier momento puede ser reemplazado por otro que pueda cumplir con la misma misión en nuestro sistema.
Todo framework o librería que nos haga desarrollar código utilizando formas que no son standards en el lenguaje que estamos desarrollando deberían ser cubiertas con una abstracción, de forma que si en un futuro queremos cambiar esa librería por otra o incluso implementarlo nosotros mismos lo podamos hacer solo haciendo un cambio en cómo se crea la implementación para esa abstracción
Esto es aplicable también a otros agentes externos tales como bases de datos, que solo cumplen una misión en nuestro sistema, que es persistir objetos. Nuestro sistema solo está interesado en persistir el objeto X pero no en la forma en la que está implementado. Por eso mismo una abstracción nos da también semántica a nuestro código, porque la abstracción en este caso se llamaría XDataStorer y podría ser implementada de múltiples formas dependiendo de la tecnología que queramos usar.
Conclusión
Implementar una arquitectura nos ayuda a entender mejor de qué trata nuestro software, a centrarnos en el dominio de nuestra aplicación, que es el valor real y que al fin y al cabo es la razón que nos lleva a escribir software. Implementar un modelo rico basado en nuestro dominio hace que todos los miembros del equipo tengan el mismo vocabulario y fuerza a ponerle nombres a conceptos por lo que facilita el entendimiento. Nos facilita también que nuestro código sea más mantenible, testable y en consecuencia nos ayuda a cumplir con los principios SOLID.
Fuente:
devexperto.com