Existem cheiros de arquitetura?

Existem muitos recursos na web referentes e listando odores de código. No entanto, nunca vi informações sobre cheiros arquitetônicos . Isso está definido em algum lugar e existe uma lista disponível? Alguma pesquisa formal foi feita sobre defeitos de arquitetura e seu impacto na velocidade do projeto, defeitos e similares?

Editar: eu realmente não estava procurando uma lista nas respostas, mas a documentação (na Web ou em um livro) sobre arquitetura cheira.

• Arquitetura multicamada Quando você tem Camadas em Camadas em Camadas em Camadas ... você vê meu ponto aqui, no seu aplicativo. Eu chamo isso de Over Layered Architecture
• Abstração excessiva de maneira que você se perca no código.
• Arquitetura futurista Isso acontece quando a solução é muito futurista. Na realidade, ninguém pode prever novos requisitos. Portanto, a maior parte da implementação futurista é apenas perda de tempo e recursos.
• Arquitetura entusiasta por tecnologia O arquiteto gostou da nova tecnologia e colocou em produção. Sem saber se foi provado antes.
• Sobre-matar a arquitetura Um problema simples foi resolvido pelo fator exponencial das habilidades e tecnologia da arquitetura.
• Arquitetura em nuvem Eu chamo de arquitetura em nuvem, já que a arquitetura não tem conexão com a realidade. São apenas alguns bons diagramas do Visio.

A total falta do oposto também é verdadeira.

Aqui está o link dos dez principais erros de arquitetura de software .

Tudo é configurável . Quando um arquiteto diz que seu sistema é à prova de alterações ou altamente personalizável por causa da ampla configuração, esse é um cheiro de arquitetura.

O problema é que você pode realmente fornecer apenas mecanismos de configuração para o que você acha que agora precisará ser configurado, mas, quando seu aplicativo estiver em estado selvagem, não será suficiente. Em seguida, os mecanismos de configuração se expandem e se expandem e, eventualmente, você obtém o Efeito da Plataforma Interna.

E então você está no inferno do software.

Um banco de dados criado por um ORM! Ou um back-end de banco de dados não relacional que deve ser relacional. Ou um banco de dados no qual você projeta usar modos de exibição que chamam modos de exibição, não apenas são muito lentos (os bancos de dados devem ser projetados para desempenho desde o início até mais tarde), mas quando você precisa fazer uma alteração, eles são horríveis de rastrear (A abstração, como o @AmirResaei disse, facilita a perda do código quando você precisa corrigir algo que está na parte inferior de todas essas camadas.)

Os odores de código e os de arquitetura são a mesma coisa. O código começa a "cheirar" por causa da arquitetura subótima.

No livro seminal de Martin Fowler sobre o tópico Refatoração , ele apresenta uma série de Code Smells e identifica uma maneira de refatorá-los do sistema. A refatoração de padrões de Joshua Kerievsky enfatiza ainda mais essa idéia, fornecendo padrões arquiteturais específicos para corrigir vários odores de código (e como refatorá-los passo a passo).

A maioria das refatorações é feita para aliviar o código abaixo do ideal por meio de arquitetura aprimorada. Alguém poderia argumentar que o único "cheiro arquitetônico" nascido naturalmente (que não seja Big Ball of Mud) seria a arquitetura BDUF (Big Design Up Front). Onde você tenta acomodar tudo o que precisa antes que a primeira linha de código seja escrita. Um projeto de software ágil, em que o design é feito conforme a necessidade (mesmo que eu diga que o código é tratado como design ), terá sua arquitetura crescer organicamente.

(Muita) Acoplamento - de qualquer forma - é o que faz as arquiteturas cheirem. Quanto mais ele é acoplado, mais ele cheira.

Dito isto: nenhum acoplamento geralmente cheira a problemas de desempenho.

Aqui está um cheiro concreto de arquitetura / design que encontro o tempo todo: análise e geração de relatórios diretamente de um banco de dados transacional.

Certamente isso é bom em algumas situações (ou seja, relatórios leves), mas em muitos casos os requisitos de processamento de transações e relatórios estão em conflito. No entanto, como é simples / barato, os relatórios são executados diretamente do banco de dados transacional. Isso causa todos os tipos de dores de cabeça nos dois lados da equação.

Isso geralmente é visto nos aplicativos Enterprise LOB, btw. Entendo que muitas pequenas e médias empresas simplesmente não têm os recursos ou o know-how para criar armazéns e datamarts (esqueça os cubos ou configurações de redução de mapa), mas muitas organizações maiores com as quais trabalhei têm os mesmos problemas.

Ao projetar um sistema, o arquiteto realmente deve estar ciente de que os relatórios - especialmente os relatórios de análise - e os requisitos transacionais são melhor tratados como problemas separados e não apenas agrupados no nível do banco de dados.

Não tenho certeza se isso se encaixa corretamente no nível da arquitetura, mas se vejo várias classes / módulos de gerente no que é suposto ser um design OO, isso é uma garantia de que a única pessoa que entenderá a arquitetura / design é o próprio arquiteto / designer sem muita explicação / aprendizado por outros.

Existem muitos odores de arquitetura documentados pela comunidade. Um conjunto comum é o seguinte.

• Dependência cíclica: esse cheiro surge quando dois ou mais componentes da arquitetura dependem um do outro direta ou indiretamente.
• Dependência instável: esse cheiro surge quando um componente depende de outros componentes que são menos estáveis ​​que ele.
• Componente de Deus: Esse cheiro ocorre quando um componente é excessivamente grande, tanto nos termos do LOC quanto no número de classes.
• Concentração de recursos: esse cheiro ocorre quando um componente percebe mais de uma preocupação / recurso de arquitetura.
• Funcionalidade dispersa: esse cheiro surge quando vários componentes são responsáveis ​​pela realização da mesma preocupação de alto nível.
• Estrutura densa: esse cheiro surge quando os componentes têm dependências excessivas e densas sem nenhuma estrutura específica.

Recentemente, preparei uma taxonomia de cheiros . Atualmente, ele documenta 38 odores de arquitetura e mais de 260 odores de código total.