Domain-Driven Design.

Enfrentar a complexidade no coração do software modelando o domínio de negócio explicitamente, e mantendo esse modelo — e o código que o expressa — em estreito alinhamento com a linguagem usada pelas pessoas que entendem o domínio.

À medida que um sistema cresce, as regras de negócio tendem a se espalhar por controllers, services e queries de banco de dados. O código se distancia de como o negócio realmente fala sobre seu trabalho, então cada conversa precisa de tradução e cada mudança arrisca quebrar uma regra de que ninguém se lembrava.

Designs centrados em dados pioram isso: os modelos viram sacos anêmicos de getters e setters, as invariantes não vivem em lugar nenhum em particular, e o sistema lentamente se transforma em uma "grande bola de lama" que poucas pessoas se atrevem a tocar.

O Domain-Driven Design ataca o problema em dois níveis.

O design estratégico divide um grande domínio em contextos delimitados — fronteiras explícitas dentro das quais um modelo e sua linguagem são consistentes — e mapeia as relações entre eles. Cada contexto é livre para modelar o mesmo conceito de forma diferente onde o negócio genuinamente o enxerga de forma diferente.

O design tático constrói um modelo rico dentro de um contexto a partir de um pequeno conjunto de blocos de construção, e insiste em uma linguagem ubíqua: os mesmos termos aparecem nas conversas, no modelo e no código.

Os blocos de construção táticos:

• Entidades — objetos definidos por uma identidade que persiste ao longo do tempo (um Customer, um Order).
• Objetos de valor — objetos imutáveis definidos por seus atributos (um Money, um Address).
• Agregados — clusters de entidades e objetos de valor com uma única raiz de agregado que protege as invariantes do cluster e é o único ponto de entrada para mudanças.
• Repositórios — interfaces semelhantes a coleções que carregam e persistem agregados inteiros, escondendo os detalhes de armazenamento.
• Serviços de domínio — operações sem estado que não pertencem naturalmente a uma única entidade.
• Eventos de domínio — registros de algo significativo que aconteceu no domínio.

Os blocos estratégicos — contexto delimitado e mapa de contextos — organizam esses modelos entre equipes e subsistemas.

• Use-o quando a complexidade central está nas regras de negócio, não na tecnologia — logística, finanças, seguros, agendamento.
• Use-o quando várias equipes precisam concordar com um entendimento compartilhado e em evolução de um domínio.
• Evite-o em aplicações simples de CRUD ou entrada de dados, onde a sobrecarga de modelagem traz pouco retorno.

1. Converse com especialistas do domínio e destile a linguagem ubíqua; anote os termos e o que eles significam.
2. Identifique o domínio central — a parte que dá vantagem competitiva — e concentre o esforço de modelagem nela.
3. Divida o domínio em contextos delimitados e desenhe um mapa de contextos com suas relações.
4. Dentro de um contexto, modele os agregados de forma que cada um imponha suas próprias invariantes em uma única transação.
5. Carregue e salve agregados por meio de repositórios; publique eventos de domínio para coisas com as quais outros contextos se importam.
6. Refine continuamente — o modelo nunca está “pronto”, ele evolui à medida que o entendimento se aprofunda.