DDD, Domain Driven Design ou Design Orientado a Domínio é um livro escrito por Eric Evans com um grande catálogo de Padrões de Desenvolvimento de Software.

Esses padrões foram definidos com base no que ele aprendeu em sua longa carreira como desenvolvedor de software orientado a objetos (OO).

No contexto do livro Domínio significa Negócio.

Por exemplo, quando se você está escrevendo um software de conta corrente para um banco, o domínio vai incluir coisas como a Conta Bancária, o Banco, a Agência, o Cliente (correntista), o Tipo de Movimento (se é um crédito ou um débito na conta), dentre outras coisas.

A principal ideia deste livro na minha visão é colocar o domínio (ou seja o negócio) no centro das atividades de desenvolvimento de software, e usar o termos e conceitos do negócio na comunicação do dia-a-dia da equipe.

Além de apresentar o conceito, o livro trás uma série de padrões (como fábricas, repositórios, entidades, objetos de valor, etc.) que podem ser utilizados para colocar essas ideias em prática através do uso de programação orientada a objetos (OO).

Linguagem Ubíqua do DDD

O código fonte, os objetos, seus atributos, e seus métodos (ou funções) devem usar os termos de negócio.

A linguagem ubíqua contém todos esses termos que fazem parte das do dia-a-adia das pessoas que vão operar o software e é essencial que o time de desenvolvimento de software entenda a fundo tudo isso antes de começar a codificar e desenvolver a solução.

Consequentemente, quanto melhor for o entendimento dessa linguagem melhor será a comunicação entre o time de desenvolvimento e áreas de negócio e mais eficiente será a solução desenvolvida por esse time.

A linguagem ubíqua passa a ser utiliza não apenas no código, mas também na comunicação do dia-a-dia, nos diálogos da equipe.

Baixo Acoplamento e Camada Anticorrupção

Dentre os diversos padrões do livro, vale a pena destacar, o conceito de Camada Anticorrupção (ou anti corruption layer) é um conceito que vem sendo cada vez mais falado nos últimos tempos, especialmente agora que os micro-serviços (microservices) estão na moda.

Esse conceito pode é utilizado para proteger o domínio do software de conceitos que não fazem parte do seu domínio, pode ser por exemplo, quando você precisa interagir com sistemas legados, sistemas externos, ou até mesmo com serviços ou microsserviços externos.

Usar esse padrão é importante para garantir que o design da sua aplicação não seja corrompido por dependências em subsistemas externos, e inclusive que o acoplamento entre esses sistema não aumente, permitindo que os sistemas possam evoluir de maneira independente.

No final do dia, a vasta maioria do sistemas dependem de outros sistemas para alguns obter dados ou extender suas funcionalidades.

A grande sacada é isolar os diferentes sistemas com uma camada anticorrupção entre eles.