Universidad Mesoamericana

Facultad de Ingeniería
Ingeniería en Sistemas
Arquitectura de Sistemas II
Rodriguez Mazariegos, German / 201608407

Arquitectura de software y sus

beneficios
por Christian Panadero Martinez | Software Craftmanship

¿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 de 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.
Qué es una arquitectura de software
Una arquitectura de software 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 arquitectónico en un proyecto de
software la propia estructura de módulos 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 de software 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, ListarProductosserí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.
COMENTARIO
La arquitectura de software en una parte muy importante al momento del desarrollo de un
sistema, ya que nos da una perspectiva mas amplia de lo que se realizará, así se puede
orientar al usuario final de como será en un futuro el sistema. La arquitectura es una
atrayente muy fuerte al momento de concertar el sistema con el cliente, porque en ella
podrá observar la idea arquitectónica que tendrá el sistema y en lo que se convertirá al
estar implementado. Cada diseño arquitectónico debe de poder explicar o dar una idea por
si solo del sistema, por lo que debe de cumplir con varios requerimientos para llegar a ser
una “arquitectura limpia” como lo describe el artículo. No solo es de diseñar la arquitectura,
sino se debe tratar de englobar todos los detalles del sistema, ya que gran parte del éxito
de su desarrollo depende de la calidad de diseño arquitectónico con que se cuente, ya que
constituye una guía para los desarrolladores.

E-grafía
https://devexperto.com/arquitectura-del-software/