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

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.