Domain-Driven Design, do início ao código

Maicon Heck
CWI Software
Published in
5 min readSep 1, 2018

👉 This article is also available in English on my blog

Quando se fala em Domain-Driven Design (DDD), muitos desenvolvedores logo se pensam no estilo arquitetural e nos tactical patterns do DDD.

E é claro que nós somos apaixonados por isso, afinal somos desenvolvedores! ❤️

Porém, para trabalhar com DDD precisamos desenvolver mais alguns skills, como aprender a modelar domínios de forma efetiva, e, para isso, precisamos nos tornar o que o Eric Evans chama de Knowledge Crunchers — processadores de conhecimento — alguém preparado para receber, filtrar e organizar uma avalanche de informação.

Domain-Driven Design é, antes de tudo, comunicação. No DDD modelagem e implementação andam juntas.

Especialistas do domínio (usuários, analistas e outros especialistas da área), juntamente com os desenvolvedores e arquitetos trabalham de mãos dadas com um objetivo em comum: construir software guiado pelo domínio para atender as necessidades do cliente.

Para fazer isso, em primeiro lugar, é necessário que todos usem uma linguagem em comum e que não haja tradução na comunicação entre os membros do time.

O time desenvolve, portanto, uma linguagem ubíqua (geral e universal) que expressa o conhecimento dos especialistas de negócio para o modelo de domínio (para o código).

Ok, eu devo guiar meu projeto pelo domínio, mas o que exatamente é o domínio?

O domínio de um software são as atividades desempenhadas pelo usuário e a área de interesse destes.

O domínio pode ser tão complexo quanto os processos e dados que ele compreende.

E o modelo?

Um modelo é, de acordo com Evans (2004, p. 2) “uma simplificação. É uma interpretação da realidade que abstrai os aspectos relevantes para resolver o problema em questão e ignorar detalhes alheios a isto” (tradução livre).

Com um modelo conseguimos:

  • Abstrair a complexidade do negócio através de uma representação simplificada do mesmo — um modelo.
  • O modelo serve como algo comum e palpável a todos os membros do time, que, junto com a linguagem ubíqua, permite que todos possam participar ativamente da construção progressiva do mesmo.
  • O modelo (desde que feito corretamente) garante que aquilo que está sendo especificado é o que está sendo implementado.
  • O modelo é o meio de comunicação usado pelo time. Graças ao vínculo entre o modelo e a implementação, os desenvolvedores podem falar na linguagem do software ao comunicarem-se com os especialistas do domínio (sem ter que traduzir a mensagem).
  • O modelo é o conhecimento destilado — é o modo como o time concorda em estruturar o conhecimento extraído do domínio.

EVANS (2004)

O modelo é evolutivo: A cada iteração entre especialistas de domínio e a equipe técnica, o modelo se torna mais profundo e expressivo, mais rico, e os desenvolvedores transferem essa fonte de valor para o software.

Assim, o modelo vai sendo gradualmente enriquecido com o expertise dos especialistas do domínio destilado pelos desenvolvedores, fazendo com que o time ganhe cada vez mais insight sobre o negócio e que esse conhecimento seja transferido para o modelo (para o código) através dos blocos de construção do DDD.

Quando novas regras de negócio são adicionadas e/ou regras existentes são alteradas ou removidas, a implementação é refatorada para refletir essas alterações do modelo no código.

No final, o modelo (que em última instância será o software) vai expressar com riqueza de conhecimento o negócio.

Como explica Evans (2004, p. 23) “DDD coloca um monte de conhecimento no modelo que reflete profundamente o domínio.”

Isso só é possível através da colaboração entre quem conhece o domínio e quem sabe criar software. 🤝

E como o desenvolvimento é iterativo, essa colaboração continua durante todo o andamento do projeto.

Ou seja, o Domain-Driven Design nos leva a construir softwares guiados pelo conhecimento e modelagem do negócio antes de qualquer apelo por tecnologia.

Dito isso, para que possamos implementar o modelo de domínio, obviamente, precisamos programar. 😎

E para isso, o DDD nos oferece os seus design patterns táticos, dentre eles eu destaco:

  • Isolamento do domínio com Layered ou Clean Architecture (a.k.a. Ports and Adapters, Hexagonal Architecture).
  • Representação do modelo através de Entities, Value Objects, Aggregates e Modules.
  • Gerenciamento do ciclo de vida dos objetos do modelo com Aggregates e Repositories.
  • Domain Services para abstrair rotinas que não se encaixam dentro do Domain Model.
  • Factory Methods para simplificar a criação de instâncias de objetos de domínio complexos.

Demonstrarei na prática cada um deles nos próximos artigos desta série sobre Domain-Driven Design. Mas agora voltemos à teoria, pois é necessário antes ter um bom fundamento se quisermos construir um modelo realmente efetivo.

Os 5 ingredientes de um modelo efetivo:

  • Vincular o modelo com a implementação: esse vínculo é feito desde o início, quando o modelo ainda é primitivo e será mantido até o fim. Esse vínculo é profundo, a implementação deve refletir 100% o modelo.
  • Cultivar uma linguagem baseada no modelo: no início será necessário que os desenvolvedores e os domain experts entendam cada um os termos do outro, mas depois ambos falarão a mesma linguagem, organizando as sentenças da comunicação numa estrutura consistente com o modelo e sem ambiguidades.
  • Desenvolver um modelo rico em conhecimento: objetos têm dados e comportamentos associados. O modelo não deve ser apenas uma estrutura de dados (modelo anêmico), ele deve capturar o conhecimento do domínio para resolver os problemas do domínio.
  • Destilar o modelo: o modelo deve ser refinado. Assim como conceitos importantes devem ser adicionados, conceitos que não tem relevância devem ser removidos. A cada iteração o modelo ficará mais rico e terá mais valor.
  • Brainstorming e experimentação: a interação direta entre os desenvolvedores e domain experts, através de brainstormings e diagramas feitos na hora, transformam as discussões em laboratórios do modelo, no qual diversas variações de experimentos podem ser exercitadas e o resultado pode ser usado se mostrar valor ou descartado caso contrário.

EVANS (2004)

O modelo deve ser rico! 💰

  • O modelo deve ser rico em conhecimento.️️️ ✔️
  • Um modelo rico é composto de código expressivo, de regras de negócio e processos bem definidos. ✔️
  • Ele expressa o conhecimento nele contido e resolve problemas do domínio.✔️
  • É o contrário de um modelo anêmico onde as classes são apenas esquemas de dados sem comportamento. 😷

Conclusão

Da próxima vez que você for inferir se um projeto está usando Domain-Driven Design, antes de olhar para a Solution Explorer da IDE em busca do estilo arquitetural e dos patterns, veja primeiro se a equipe está usando um método ágil e fazendo knowledge crunching.

Eu já vi muitos projetos autodenominados “com DDD”, que apesar de implementarem alguns dos tactical patterns do DDD, o modelo estava bem longe de refletir o domínio.

Referências

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

Veja a continuação dessa série:

Maicon Heck
.NET Senior Developer | Software Craftsman | Domain-Driven Design practitioner

blog | github | linkedin | twitter

--

--

Maicon Heck
CWI Software

I'm a software crafter. Through DDD I crafted dozens of rich, extensible, testable, and long-lived business domain models.