Es hora de echar un nuevo vistazo a los postulados que no han cambiado a lo largo de los años. Un mundo que cambia dinámicamente dicta sus propias reglas, incluso en la arquitectura de computadoras. Los cambios que se están produciendo requieren nuevos enfoques, lo que obliga a los sistemas rígidos a ser flexibles y adaptarse a las nuevas condiciones. ¿Es posible la planificación a largo plazo si todo cambia constantemente? ¿Cómo evitar el deterioro gradual de la solución arquitectónica con el tiempo? Aquí encontrará respuestas y recomendaciones que protegerán las características más importantes del proyecto en el contexto de cambios continuos. “Este libro marca un hito importante en la comprensión actual del problema. A medida que las personas toman conciencia del papel del software en el siglo XXI, la información sobre cómo responder al cambio mientras se mantiene lo que se ha logrado se convierte en una habilidad esencial en el desarrollo de software ". - Martin Fowler
Arquitectura evolutiva: trampas y antipatrones
Pasamos mucho tiempo discutiendo los niveles adecuados de conectividad en la arquitectura. Sin embargo, también vivimos en el mundo real y observamos muchas interconexiones que perjudican la capacidad de evolución del proyecto.
Se han identificado dos malas prácticas de diseño que son evidentes en los proyectos de software: trampas y antipatrones. Muchos desarrolladores usan la palabra antipatterns como el término de argot "malo", pero su significado real necesita ser aclarado. El software antipatrón consta de dos partes. Primera parte: antipatrón es una práctica que inicialmente parece una buena idea, pero se convierte en un error. Segunda parte: para la mayoría de los antipatrones, hay muchas alternativas mucho mejores. Los desarrolladores de arquitectura notan muchos antipatrones solo en retrospectiva, por lo que es difícil evitarlos. La trampa a primera vista parece una buena idea, pero inmediatamente se manifiesta como una mala manera. En este capítulo, nos fijamos en trampas y antipatrones juntos.
Arquitectura técnica
Esta sección se centra en la práctica común utilizada en la industria, lo que es particularmente perjudicial para la capacidad del equipo para evolucionar la arquitectura.
Antipatrón: Rey vendedorAlgunas grandes empresas compran software de Planificación de Recursos Empresariales (ERP) para resolver tareas comerciales comunes, como contabilidad, gestión de inventario y otras operaciones de rutina. Esto funciona si las empresas están listas para doblar sus procesos de negocio y otras soluciones para adaptar esta herramienta, y puede usarse estratégicamente cuando los desarrolladores de arquitectura entiendan las limitaciones y ventajas.
Sin embargo, muchas organizaciones se vuelven demasiado ambiciosas con respecto al software de esta categoría, lo que lleva al antipatrón del rey vendedor, cuya arquitectura se basa completamente en los productos del proveedor, lo que patológicamente une a la organización a esta herramienta. Las compañías que compran software de proveedor planean aumentar el paquete con sus complementos para expandir la funcionalidad básica para alinearlo con el área temática de la empresa. Sin embargo, durante mucho tiempo, la herramienta ERP no se puede configurar lo suficiente como para implementar completamente lo que se necesita, y los desarrolladores se encuentran indefensos como resultado de las limitaciones de la herramienta y porque la convirtieron en el centro del universo arquitectónico. En otras palabras, los desarrolladores de arquitectura hicieron al proveedor del rey de su arquitectura, dictando decisiones futuras.
Para evitar el antipatrón, uno debería considerar el software simplemente como otro punto de integración, incluso si inicialmente tenía una amplia gama de responsabilidades. Asumiendo la integración en la etapa inicial, es más fácil cambiar características inútiles con otros puntos de integración, derribando al rey del trono.
Al colocar una herramienta o plataforma externa en el corazón de la arquitectura, los desarrolladores han limitado significativamente su capacidad de evolucionar en dos direcciones principales, a saber, técnicamente y desde el punto de vista del proceso comercial. Los desarrolladores están técnicamente limitados por la elección del proveedor con respecto a los sistemas de almacenamiento, la infraestructura compatible y muchas otras restricciones. Desde el punto de vista del área temática, una herramienta de encapsulación grande finalmente sufre del antipatrón "Trampa en el último 10%". Desde el punto de vista del proceso empresarial, esta herramienta no puede soportar un flujo de trabajo óptimo; Este es un efecto secundario o trampa en el último 10%. La mayoría de las empresas cierran mediante el envío a la plataforma, reemplazando procesos, en lugar de tratar de personalizar la herramienta. Mientras más compañías hagan esto, las características menos distintivas existen entre las compañías, lo cual es genial porque la diferencia no es una ventaja.
El principio
para detener el trabajo y llamarlo éxito es uno de los que los desarrolladores suelen tener en cuenta al tratar con paquetes ERP en el mundo real. Dado que requieren importantes inversiones de tiempo y dinero, las empresas son reacias a aceptarlas cuando no trabajan. Ningún departamento técnico quiere aceptar la pérdida de millones de dólares, y el proveedor de la herramienta no quiere aceptar una mala implementación de múltiples capas. Por lo tanto, cada una de las partes acuerda detener el trabajo y llamarlo éxito con la mayoría de las funcionalidades prometidas incumplidas.
No asocie su arquitectura con el rey proveedor.
En lugar de caer presa del antipatrón del rey proveedor, considere mirar los productos proveedores como otro punto de integración. Los desarrollos pueden aislar los cambios en la herramienta del proveedor del impacto de su arquitectura al crear capas de resistencia a la destrucción entre los puntos de integración.
Trampa: abstracción holey
Todas las abstracciones no triviales están, en cierta medida, llenas de agujeros.
- Joel Spolsky
El software moderno se basa en una torre de abstracciones: sistemas operativos, plataformas, dependencias, etc. Como desarrolladores, construimos abstracciones de tal manera que no tenemos la capacidad de pensar constantemente mientras estamos en los niveles inferiores. Si los desarrolladores necesitan traducir los números binarios que provienen de los discos duros al texto del programa, ¡nunca podrán hacer nada! Uno de los triunfos del software moderno es qué tan bien podemos construir abstracciones efectivas.
Pero las abstracciones son caras, porque no hay abstracciones perfectas, y si lo fueran, no serían abstracciones, sino algo real. Según Joel Spolsky, todas las abstracciones no triviales tienen un agujero (fuga). Este es un problema para los desarrolladores porque creemos que las abstracciones son siempre precisas, pero a menudo colapsan maravillosamente.
La creciente complejidad de las pilas de tecnología ha convertido recientemente la abstracción en un problema devastador. En la fig. 7.1 presenta una pila tecnológica típica que data de aproximadamente 2005.
En esta pila, el nombre del proveedor en los bloques cambia según las condiciones locales. Con el tiempo, a medida que el software se vuelve más especializado, nuestra pila de tecnología se vuelve más compleja, como se muestra en la Figura 2. 7.2.
Como se puede ver en la fig. 7.2, cada parte del ecosistema de software se ha expandido y se ha vuelto más complejo. A medida que los problemas que enfrentan los desarrolladores se vuelven cada vez más complejos, también lo son sus soluciones.
La abstracción holey inicial , donde la abstracción destructiva de bajo nivel conduce a un caos inesperado, es uno de los efectos secundarios de aumentar la complejidad de la pila de tecnología. ¿Qué sucede si una de las abstracciones en el nivel más bajo falla, por ejemplo, algún efecto secundario inesperado de una llamada a una base de datos aparentemente inofensiva? Dado que hay tantas capas, esta falla se moverá a la parte superior de esta pila, posiblemente causando "metástasis" en su camino, manifestándose en un mensaje de error profundamente incrustado en la interfaz de usuario. La depuración y el análisis retrospectivo se vuelven más difíciles cuanto más compleja es la pila tecnológica.
Intente comprender completamente al menos un nivel de abstracción por debajo del nivel en el que trabaja habitualmente.
- Software de sabios
Si bien comprender la siguiente capa es un buen consejo, cada vez es más difícil de seguir a medida que el software se especializa y se vuelve más complejo.
El aumento de la complejidad de la pila tecnológica es un ejemplo de un problema de equilibrio dinámico. No solo cambia el ecosistema, sino que sus partes constituyentes se vuelven más complejas y confusas con el tiempo. El mecanismo propuesto para proteger los cambios en evolución, es decir, el uso de funciones de aptitud, puede proteger los puntos frágiles de las conexiones de arquitectura. Los arquitectos definen invariantes en los puntos clave de integración, como las funciones de idoneidad, que funcionan como parte de la canalización de implementación, asegurando que la abstracción no comience a fluir de manera indeseable.
»Se puede encontrar más información sobre el libro en
el sitio web del editorPara habrozhitelami 20% de descuento en cupones -
Arquitectura evolutiva