¿Hay olores de arquitectura?

Hay toneladas de recursos en la web que hacen referencia y enumeran olores de código. Sin embargo, nunca he visto información sobre olores arquitectónicos . ¿Está definido en alguna parte, y hay una lista disponible? ¿Se ha realizado alguna investigación formal sobre defectos de arquitectura y su impacto en la velocidad del proyecto, defectos y similares?

Editar: Realmente no estaba buscando una lista en las respuestas, sino documentación (en la web o en un libro) sobre olores de arquitectura.

• Arquitectura multinivel Cuando tienes capas en capas en capas en capas ... ves mi punto aquí, en tu aplicación. Lo llamo sobre arquitectura en capas
• Sobre abstracción de tal manera que te pierdas en el código.
• Arquitectura futurista Esto sucede cuando la solución es demasiado futurista. En realidad, nadie puede predecir nuevos requisitos. Por lo tanto, la mayor parte de la implementación futurista es solo una pérdida de tiempo y recursos.
• Arquitectura entusiasta de la tecnología Al arquitecto le gustó la nueva tecnología y la puso en producción. Sin saber si se probó antes.
• Over Kill Architecture Un problema simple se resolvió mediante el factor exponencial de las habilidades y la tecnología de la arquitectura.
• Arquitectura en la nube La llamo arquitectura en la nube ya que la arquitectura no tiene conexión con la realidad. Son solo algunos bonitos diagramas de Visio.

La falta total de lo contrario también es cierto.

Aquí hay un enlace de los diez errores principales de la arquitectura de software .

Todo es configurable . Cuando un arquitecto le dice que su sistema es a prueba de cambios o altamente personalizable debido a su amplia capacidad de configuración, es un olor a arquitectura.

El problema es que realmente solo puede proporcionar mecanismos de configuración para lo que cree que en este momento va a necesitar configurarse, pero una vez que su aplicación esté en estado salvaje, no será suficiente. Luego, los mecanismos de configuración se expanden y expanden, y eventualmente obtienes el efecto de plataforma interna.

Y luego estás en el infierno del software.

¡Una base de datos diseñada por un ORM! O un backend de base de datos que no es relacional y que debería ser relacional. O una base de datos donde diseñe para usar vistas que llaman vistas que llaman vistas, no solo son demasiado lentas (las bases de datos deben estar diseñadas para el rendimiento desde el principio y no más tarde) sino que cuando necesita hacer un cambio, es horrible rastrearlas (Sobre la abstracción, como dijo @AmirResaei, es fácil perderse en el código cuando necesita arreglar algo que está en la parte inferior de todas esas capas).

Los olores de código y los olores arquitectónicos son lo mismo. El código comienza a "oler" debido a una arquitectura subóptima.

En el libro seminal de Martin Fowler sobre el tema, Refactorización , presenta una serie de olores de código e identifica la forma de refactorizarlos de su sistema. Refactoring to Patterns de Joshua Kerievsky enfatiza aún más esta idea al dar patrones arquitectónicos específicos para arreglar varios olores de código (y cómo refactorizarlos paso a paso).

La mayor parte de la refactorización se realiza para aliviar el código subóptimo a través de una arquitectura mejorada. Se podría argumentar que el único "Olor Arquitectónico" nacido naturalmente (aparte de Big Ball of Mud) sería la Arquitectura BDUF (Big Design Up Front). Donde intenta acomodar todo lo que necesita antes de escribir la primera línea de código. Un proyecto de software ágil donde el diseño se realiza según sea necesario (incluso me atrevo a decir que el código se trata como diseño ), hará que su arquitectura crezca orgánicamente.

(Una gran cantidad de) El acoplamiento, en cualquier forma, es lo que hace que las arquitecturas huelan. Cuanto más se junta, más huele.

Dicho esto: ningún acoplamiento a menudo huele a problemas de rendimiento.

Aquí hay un olor a arquitectura / diseño concreto que encuentro todo el tiempo: análisis e informes directamente desde una base de datos transaccional.

Esto sin duda está bien en algunas situaciones (es decir, informes ligeros), pero en muchos casos los requisitos de procesamiento de informes y transacciones están en conflicto. Sin embargo, debido a que es algo simple y económico, los informes se ejecutan directamente desde la base de datos transaccional. Esto causa todo tipo de dolores de cabeza en ambos lados de la ecuación.

Esto se ve típicamente en las aplicaciones Enterprise LOB, por cierto. Entiendo que muchas PYMES simplemente no tienen los recursos o el conocimiento para crear almacenes y datamarts (olvídate de los cubos o configuraciones de reducción de mapas), pero muchas organizaciones más grandes con las que he trabajado tienen los mismos problemas.

Al diseñar un sistema, el arquitecto realmente debe ser consciente de que los informes, especialmente los informes de análisis, y los requisitos transaccionales se tratan mejor como problemas separados y no solo agrupados a nivel de la base de datos.

No estoy seguro de si esto encaja correctamente en el nivel de arquitectura, pero si veo un montón de clases / módulos de administrador en lo que se supone que es un diseño OO, entonces eso es una garantía de que la única persona que entenderá la arquitectura / diseño es el arquitecto / diseñador mismo sin mucha explicación / aprendizaje por parte de otros.

Hay muchos olores de arquitectura documentados por la comunidad. Un conjunto común es el siguiente.

• Dependencia cíclica: este olor surge cuando dos o más componentes de la arquitectura dependen el uno del otro directa o indirectamente.
• Dependencia inestable: este olor surge cuando un componente depende de otros componentes que son menos estables que él.
• Componente de Dios: este olor ocurre cuando un componente es excesivamente grande, ya sea en términos de LOC o número de clases.
• Concentración de características: este olor se produce cuando un componente se da cuenta de más de una preocupación / característica arquitectónica.
• Funcionalidad dispersa: este olor surge cuando múltiples componentes son responsables de darse cuenta de la misma preocupación de alto nivel.
• Estructura densa: este olor surge cuando los componentes tienen dependencias excesivas y densas sin ninguna estructura en particular.

Recientemente preparé una taxonomía de olores . Actualmente, documenta 38 olores de arquitectura y más de 260 olores de código total.