Na série de recortes de trechos de trabalhos acadêmicos que fiz no passado sobre DDD (Domain-Driven Design)... aqui vai a parte 7 contendo trechos do capítulo 5 e 6 de meus resumos sobre DDD. Geralmente, os padrões táticos do DDD são os mais conhecidos na comunidade de Desenvolvimento de Software, por isso, vale lembrar que também existem as técnicas de modelagem estratégica do DDD.

>

5.7 Fábrica

O padrão do DDD conhecido como Fábrica deve ser utilizado sempre que for necessário criar novas instâncias de objetos do tipo entidade, valor objeto, serviço, agregado ou outros objetos cuja complexidade envolvida nas regras de criação destes objetos não sejam de responsabilidade da classe cliente (Vernon, 2013) e (Evans, 2011).

Segundo Vernon (2013), a implementação do padrão Fábrica do DDD também poderá seguir os padrões de criação descritos em Gamma et al (1998). Porém quando se cria instâncias de agregados deve-se garantir a aplicação de suas invariantes (Evans, 2003).

5.8 Repositório

A conceitualização e explicação completa sobre o padrão Repositório usado no DDD pode ser encontradas na obra original de Evans (2003) e diferentes implementações são sugeridas em Vernon (2013). O detalhamento deste padrão vai além do escopo desta monografia.

Desta maneira, um resumo sobre este padrão foi feito posteriormente por Evans (2011), no qual é citada a complexidade envolvida nas operações de persistência de dados.

Tal complexidade técnica resulta na inclusão de detalhes de implementação referentes à infraestrutura de acesso a banco de dados nos códigos das classe clientes que compõe a camada de domínio, deixando o modelo confuso ou irrelevante (Evans, 2011).

Para se evitar a deterioração do modelo, o padrão Repositório é utilizado com o intuito de abstrair esta complexidade e fornecer consultas de acesso aos Agregados utilizando as expressões da linguagem ubíqua (Evans, 2011).

Na prática, para cada Agregado que precisar ser acessado globalmente, um Repositório deverá ser fornecido para prover a ilusão de uma coleção de dados in-memory, expondo uma interface cujos nomes dos métodos sigam a linguagem ubíqua (Vernon, 2013) e (Evans, 2011).

6. Arquitetura de Sistemas construídos com o DDD

Evans (2011) sugere o uso de Arquiteturas em Camadas para implementações construídas tendo o DDD como abordagem de desenvolvimento de software.

O objetivo é isolar o modelo de domínio em sua própria camada e manter as regras de negócio organizadas numa só camada, livrando o modelo de influências das outras possíveis camadas como infraestrutura, interfaces de usuário e persistência de dados (Evans, 2011).

Mas no geral, outros estilos de arquitetura como hexagonal*, event-driven, CQRS, SOA, REST ou Sagas poderiam ser implementadas com o DDD (Vernon, 2013).

Neste último ano, particularmente, também acho interessante explorar os conceitos do DDD relacionados aos Contextos Delimitados e as possibilidades de usar arquiteturas modernas como Microserviços.

Pra quem chegou até aqui... espero que estes artigos sobre conceitos básicos do DDD tenham sido úteis.

*Obs.: Este padrão de arquitetura é atribuído a Alistair Cockburn

(https://alistair.cockburn.us/hexagonal-architecture)

Referências

Vernon, 2013: Vernon, Vaughn , Implementing Domain-Driven Design, 2013

Evans, 2003: Evans, Eric , Domain-Driven Design: Tackling the Complexity in the Heart of Software, 2003

Evans, 2011: Evans, Eric, Domain-Driven Desgin Reference, 2011