Robert C. Martin en su libro “Clean Architecture: A Craftsman's Guide to Software Structure and Design” muestra una perspectiva muy acertada de lo que es la arquitectura y el diseño del software. En el capítulo 1 dice:
“La palabra arquitectura se usa a menudo en el contexto de algo de alto nivel que es contrapuesto a algo de bajo de nivel, mientras que diseño parece que implica decisiones de bajo nivel. Esta separación entre arquitectura y diseño no tiene sentido si se mira a lo que hace un arquitecto de software en su día a día.
Considere el arquitecto que diseño mi nueva casa. ¿Tiene la casa una arquitectura? Por supuesto que la tiene. ¿Y en qué consiste esa arquitectura? Pues contiene la forma de la casa, el aspecto exterior, la elevación del terreno y el diseño de los espacios y habitaciones. A medida que analizo los diagramas que el arquitecto me ha preparado, veo una inmensa cantidad de detalles. Veo donde se colocará cada interruptor, cada enchufe y cada punto de luz. Veo que interruptores manejan que luces. Veo dónde está colocado el horno y el tamaño y la ubicación del calentador de agua y la bomba de desagüe. Veo descripciones detalladas de cómo se construirán las paredes, los techos y los cimientos.
En resumen, veo todos los pequeños detalles que dan soporte a las decisiones de alto nivel. En definitiva los detalles y las decisiones de alto nivel son parte de un todo que es la casa que se construirá.
Lo mismo pasa con el diseño de software. Los detalles de bajo nivel y las estructuras de alto nivel son parte de un todo. Forman un tejido continuo que define la forma del sistema. No se puede tener uno sin el otro, por lo tanto no hay una clara línea que los divida. Son realmente un continuo de toma de decisiones desde el nivel de detalle más alto al más bajo.
El objetivo de la arquitectura del software no es más ni menos que minimizar los recursos humanos necesarios para construir y mantener el sistema.
La medida de la calidad de la arquitectura y el diseño del software puede ser simplemente la medida del esfuerzo requerido para cumplir con los requisitos del cliente. Si el esfuerzo es pequeño, y permanece bajo a lo largo de la vida del sistema el diseño es bueno. Si el esfuerzo crece con cada nueva versión, el diseño es malo. Es tan simple como esto.”
La forma de conseguir una buena arquitectura para un sistema software es más compleja a medida que el sistema a construir es más complejo. La complejidad no es la misma si estamos construyendo una web para la venta online de una pequeña librería que si el sistema es una app para acceder a un banco en la cual podemos hacer todo tipo de operaciones, desde transferencias de dinero, abrir una cuenta, invertir en fondos, etc . Cuanto más complejo es el sistema, más importante es que la arquitectura y el diseño sean de calidad.
Cuando se trata de sistemas complejos es difícil plantear una arquitectura idónea al comienzo de la construcción. Esto se debe a que al inicio todo son hipótesis, no hay nada construido sobre lo que probar la efectividad de las estructuras y abstracciones ideadas. Es por esto que actualmente existe una corriente dentro de los “Métodos Ágiles” que invita a crear la arquitectura poco a poco, sin empezar por establecer estructuras rígidas desde el comienzo del desarrollo. Lo importante es encontrar un equilibrio y no implantar estructuras más complejas, ni más simples de lo necesario.
Un inicio de lo que supone construir una arquitectura flexible y ajustada a las necesidades del sistema que se va a construir la aportó Peter De Grace con la Arquitectura Sashimi en 1990 en el libro “Wicked Problems, Righteous Solutions: A Catalog of Modern Software Engineering Paradigms” que se puede leer de forma gratuita registrándose en la web Internet Archive.
Para sistemas construidos con lenguajes basados en el paradigma de Orientación a Objetos, que son los que actualmente están más en boga, existen arquitecturas de referencia acuñadas por reconocidos expertos. Estas arquitecturas recomiendan estructuras genéricas altamente cohesionadas y poco acopladas que hacen uso de las herramientas suministradas por el paradigma OO, concretamente uno de los elementos más extensivamente usado son los interfaces.
Estás son:
- Arquitectura Onion de Jeffrey Palermo. Se puede consultar en Arquitectura onion
- Arquitectura Hexagonal de Alistar Cockburn. Se puede consultar en Arquitectura hexagonal
-
Clean Arquitecture de Robert C. Martin que está ampliamente explicada en su libro “Clean Architecture: A Craftsman's Guide to Software Structure and Design: A Craftsman's Guide to Software Structure and Design” que se puede comprar en:
No hay comentarios:
Publicar un comentario