¦ M ! L Є S i • B Λ S Γ Ø S ¦

É preciso, inicialmente, observar que um dos primeiros indicadores de qualidade na arquitetura de software foi o baixo acoplamento. Aparecendo juntamente com a coesão no início do desenvolvimento estruturado e nunca mais deixando de ser considerado em arquitetura de software.

Segundo (Fowler, 2001) em seu artigo, o acoplamento geralmente ocorre quando uma camada da aplicação precisa acessar outra camada, seja para executar métodos ou acessar algum dado. (Gamma, 2005) falou em sua entrevista sobre os dois principais pontos referentes a um baixo acoplamento: “programe para uma interface, não para uma implementação” e “prefira uma composição de objetos a uma herança”.

Além disso, entre os vários tipos de coesão. Dois dos mais utilizados são a coesão comunicacional e coesão funcional. A coesão comunicacional é quando partes do módulo operam os mesmos dados. Faz sentido agrupá-los, porque existe uma forte relação entre eles. A coesão funcional é quando todas as partes do módulo trabalham em conjunto para executar uma tarefa bem definida. Este é considerado o melhor tipo de coesão.

Referências:

Reducing Coupling. Fowler, Martin. 2001. Julho/Agosto 2001, IEEE Software, pp. 102-104.
Gamma, Erich. 2005. Design Principles from Design Patterns. [interv.] Bill Venners. Junho 06, 2005.

Em seu trabalho, (Evans, 2003) observa que qualquer domínio pode ser expresso em vários modelos e qualquer modelo pode ser codificado de várias maneiras. Dentre essas maneiras, temos que considerar os princípios de arquitetura de software, como vamos abordar a transição do modelo para o código e como essa arquitetura poderá evoluir durante o processo de desenvolvimento.

Também, (Avram, et al., 2006) destacam ainda que um modelo correto pode não ser expresso em código ou acabar quebrando algum princípio de arquitetura de software. Diante disso, é preciso definir um modelo que seja fácil e precisamente codificado.

A questão fundamental aqui é: como vamos abordar a transição do modelo para o código?

Vale ressaltar que um dos principais problemas das arquiteturas é que os arquitetos não conseguem prever todos os possíveis cenários e detalhes de um domínio. Detalhes muito importantes são descobertos durante a implementação e um modelo válido para o domínio poderá apresentar sérios problemas com a persistência ou mesmo um desempenho inaceitável entre outros.

Sendo assim, a arquitetura deve evoluir durante o processo ou os desenvolvedores serão obrigados a tomar algumas decisões por conta própria, fazendo alterações na arquitetura a fim de resolver problemas reais que não foram considerados quando o modelo foi criado.

Dessa forma, (Evans, 2003) sugere que para manter a consistência entre o modelo e sua implementação são necessárias ferramentas de desenvolvimento e linguagens que suportem o paradigma de modelagem que está sendo proposto.

Diante disso, a programação orienta a objetos é adequada para a implementação do modelo de domínio porque ambos são baseados no mesmo paradigma fornecendo classes de objetos, associações e troca de mensagens entre eles, mapeando diretamente os objetos do modelo.

Referências:

Evans, Eric. 2003. Domain-Driven Design: Tackling Complexity in the Heart of Software. Boston : Addison-Wesley Professional, 2003.
Avram, Abel and Marinescu, Floyd. 2006. Domain-Driven Design Quickly. 2006.

Do design centrado nos dados a orientação a domínio

Em seu trabalho, (Avram, et al., 2006) destaca que o desenvolvimento de software é, na maior parte dos casos, utilizado para automação de processos ou resolver problemas de negócio. Os processos de negócio ou problemas a serem resolvidos são o domínio do software. Nós temos que entender, desde o início, que o software é derivado deste domínio e está diretamente relacionado a ele.

Em suma, o software deve seguir o modelo do domínio. Essa é a melhor maneira de fazer o software refletir um domínio específico. Ele precisa incorporar os conceitos fundamentais e os elementos do domínio, percebendo as relações entre eles.

Arquitetura Centrada nos Dados

Podemos observar que devido à impedância entre os mundos objeto e relacional, é comum encontrarmos soluções de arquitetura onde o domínio da aplicação está fortemente acoplado a camada de acesso a dados. Essa é uma questão encontrada principalmente quando uma abordagem de arquitetura centrada nos dados é utilizada.

Nessa abordagem, a modelagem da estrutura dos dados é a peça central. O banco de dados é a parte mais importante dessa arquitetura e o Administrador de Dados desempenha um papel fundamental.

No entanto, uma abordagem centrada nos dados pode ser bem utilizada quando temos um cenário para aplicações de formulários sobre dados que não envolvam processos de negócio complexos.

Arquitetura Orientada a Domínio

Como (Avram, et al., 2006) definem, a Arquitetura Orientada a Domínio combina arquitetura e práticas de desenvolvimento. Dentre tantos fatores, eles destacam como a arquitetura e o desenvolvimento podem trabalhar juntos para criar uma solução melhor.

Dessa maneira, uma boa arquitetura vai acelerar o desenvolvimento, enquanto o feedback proveniente do processo de desenvolvimento irá melhorar a arquitetura.

Referências:

Avram, Abel and Marinescu, Floyd. 2006. Domain Driven Design Quickly. 2006.

É notório que a crescente adoção de metodologias ágeis de desenvolvimento exigiu novas abordagens de engenharia de software. Essas abordagens desafiam muitos conceitos comuns sobre o Desenvolvimento Planejado de Software. Dentre tantos fatores, um dos mais polêmicos é a rejeição ao grande esforço realizado na fase inicial do projeto sugerindo uma abordagem evolutiva.

Nessa abordagem, a arquitetura de software deve adotar práticas que ajudem a definir uma estratégia de arquitetura evolutiva. Como @KentBeck observa, a arquitetura existe para possibilitar a evolução do software, com facilidade, a longo prazo.

Uma arquitetura deteriorada prejudica a capacidade de implementar mudanças com segurança. Nesse estado de entropia do software, com o tempo a arquitetura piora ainda mais. O software fica difícil de manter e vulnerável a bugs cada vez piores de serem identificados e corrigidos. Nesse processo de “codifica-remenda”, com o passar do tempo, os bugs tornam-se exponencialmente mais caros de corrigir.

Diante disso, como planejar uma estratégia de arquitetura capaz de evoluir junto com o código?

Definir um modelo de Arquitetura Orientada ao Domínio, um conjunto de padrões de arquitetura para aplicações corporativas, adotar boas práticas e beneficiar-se do avanço das tecnologias e ferramentas de desenvolvimento irá nos guiar no planejamento de uma estratégia de arquitetura evolutiva capaz de suportar o processo de desenvolvimento ágil.

Referências:

Is Design Dead? por Martin Fowler
Agile Brazil Keynotes por Martin Fowler