Quero aplicar DDD, por onde começo?

DDD é um BuzzWord bem difundido. Pessoas desenvolvedoras já ouviram falar bastante, algumas já implementaram, com e sem sucesso. A maioria admira, mas tem também um pequeno grupo que acha um desperdício de tempo.

A sigla significa Domain Driven Design, em (quase) português, Design Orientado a Domínio. Ao contrário do que algumas pessoas pensam quando se deparam com o termo pela primeira vez, esse padrão não tem nada a ver com testes ou TDD.

Antes de dizer de fato o que é DDD, eu vou começar pelo mais fácil, dizendo o que não é DDD.

• Microsserviço não é DDD
• Linguagem, paradigma ou framework específicos não é DDD
• Design Pattern não é DDD
• BDD teste não é DDD

Afinal, o que é DDD então?

O DDD (Domain-driven Design) é uma abordagem para o desenvolvimento de software para necessidades complexas, conectando profundamente a implementação a um modelo em evolução dos principais conceitos de negócios. — Comunidade de DDD

Através de nomenclatura, tipagem e regras de negócio explicitamente definidas, dentre outras práticas, nós chegamos muito perto de conseguir isso.

1. Nomenclatura

Principalmente se você estiver refatorando um código já existente, esse é um bom pontapé inicial. Usar nomes que equivalem ao utilizado no mundo real parece ser simples, mas muitas vezes é difícil encontrar quem possa ajudá-lo na tarefa de descobrir esses termos.
No contexto de DDD, chamamos essa pessoa de Domain Expert, ou Especialista de Domínio. Essa pessoa não é necessariamente técnica, ela conhece o negócio profundamente, a ponto de te ajudar com uma das tarefas mais difícil de pessoas desenvolvedoras: nomear.
Começar pelas entidades é uma ótima. Ter uma consistência nesse nome durante todo o código, quando se trata do mesmo contexto, também.
No final dessa tarefa você vai ter o que o DDD referencia como Ubiquitous Language, ou Linguagem Ubíqua. Ou seja, teremos um único vocabulário para utilizar, seja falando de negócio ou falando de código.
Depois você pode começar a expressar melhor o que é cada objeto em cada parte do seu sistema. Um padrão muito utilizado para transitar objetos é o DTO e nesse artigo eu dou algumas dicas também sobre a nomenclatura deles.

2. Tipagem

Se você cumpriu o primeiro passo, deve ter percebido que nem tudo se encaixou tão bem assim. Pode ser que tenham contextos no negócio que não necessariamente tem um tipo associado a ele no código, ou você tem vários objetos que você não sabe nem o que são, e por isso não conseguiu nomear corretamente.
Se você utiliza Orientação a Objetos com uma linguagem fortemente tipada, você tem tudo para resolver isso.
Preocupe-se em ter tipos bem definidos para as suas entidades de domínio, e procure também separar os tipos por contexto (ou Bounded Context).
Você pode ter uma entidade que de início parece ser uma coisa só, mas a aplicação dela é em contextos tão diferentes, que faz perder o sentido você agregar tudo em um objeto só.

Exemplo prático: na minha aplicação de Compras eu tenho um Cliente.
Um Cliente pode efetuar uma compra, fazer um login, ou colocar um objeto à venda. Apesar de ser o mesmo cliente na vida real, os contextos em que ele atua são tão diferentes, e os dados sobre Cliente também são diferentes, bem como as regras de negócio aplicadas. Logo, talvez faça mais sentido você não ter uma representação única de Cliente no sistema, mas talvez uma para cada cenário.

3. Regras de negócio explicitamente definidas

Se você tem uma linguagem ubíqua e definiu bem seus tipos de acordo com os Bounded Contexts, fica muito fácil de deixar suas regras de negócio cada vez mais explícitas para quem lê, e também para que seja fácil de mudar. Porque um dos benefícios de aplicar DDD é a flexibilidade das regras de negócio.

Um passo importante para isso é mover todas as suas regras de negócio para dentro do domínio. Como nós não tínhamos as entidades muito bem definidas, ficava difícil entender onde escrever as regras de negócio. E nesse cenário, o lugar favorito é nos serviços de aplicação (naquela camada que orquestra chamadas para repositórios e serviços externos). O que acontece na maioria dos casos é que essa lógica fica perdida no código, muitas vezes mal testada, duplicada, e de difícil manutenção.

A tarefa agora então é achar esses trechos de código, e transferi-los para dentro do domínio.

Conclusão

Essas três tarefas irão te dar uma base ótima para começar a se aprofundar em práticas e conceitos do DDD.

Para os conceitos, sem sombra de dúvidas eu recomendo ler o livro do Eric Evans (aquele famoso livro azul que aparece na imagem acima) mas o livro de capa vermelha, Domain Driven Design Distilled escrito pela comunidade é um ótimo resumo também.

Quanto a práticas, eu recomendo fortemente a leitura desse artigo do Maniero, manipulando mais que bytes, é tão bom que eu nem me preocupei em falar sobre isso de novo aqui. 😃

E antes de se preocupar em mudar todos os codebases do mundo, leia também esse artigo que eu falo sobre quando usar DDD.

Como vocês podem ver, não tem uma receita e um padrão bem definido para colocar DDD em prática. É muito mais uma mentalidade que vai te ajudar a escrever código com mais qualidade.