Uma noite dessas, assisti uma palestra sobre TDD. O palestrante não parava de falar, no entanto, sobre como DDD facilitava o controle da persistência dos dados. Como queria escrever um pequeno framework de persistência, não tive dúvidas: Comprei um livro e comecei a estudar. O que descobri foi interessantíssimo.
DDD não tem nada a ver com isso. Pelo menos não principalmente
Talvez a melhor forma de entender o que é o Domain Driven Desing, é tentar colocá-lo numa estante de livros. Ao lado de que livro você colocaria o livro de DDD?
Desing Patterns
Não importa a linguagem, você pode implementar os padrões de projeto para resolver problemas cotidianos. Eles são soluções já testadas e amplamente utilizadas pela comunidade de desenvolvedores. Como o próprio nome diz, eles são padrões. Como se fossem uma forma inicial, da qual você pode derivar novas implementações. Nem todo builder, por exemplo, necessita de um director. O que revela algo importante: Os Design Patterns são padrões de implementação de código.
E é exatamente por isso que DDD não poderia ser colocado ao lado de GoF. DDD não é um padrão de implementação. Você não tem uma classe TClienteDDD. Contudo, para utilizar DDD em seu projeto, você fará uso de muitos padrões de projeto. Alguns presentes no próprio GoF, outros presentes no Padrões de Arquitetura de Aplicações Corporativa, de Martin Fowler.
Boas práticas
Uncle Bob é uma das pessoas mais proeminentes e respeitadas por toda a comunidade de programadores. No seu livro, Robert C. Martin, revela boas práticas de programação que auxiliam os desenvolvedores a produzirem código de melhor qualidade e muito mais legíveis. Por essas características apenas, o próprio código já se torna mais resistente a bugs e aumenta consideravelmente a manutenabilidade do código.
DDD também se preocupa com a legibilidade do código. Em um nível superior ainda! A ideia é que o próprio Product Owner possa bater os olhos no código e entender o que ele faz. É o que Eric Evans chamou de Linguagem Ubíqua. Porém DDD não pode ser resumido à sua linguagem ubíqua. Existem uma série de outros dispositivos, requisitos, conceitos que fazem o DDD ser o que é e funcionar.
O que é o DDD então?
Você tem uma aplicação e precisa começar a desenha-la. Conforme o lápis risca o papel, você percebe que algumas daquelas “coisas” já estão prontas em outros módulos que você escreveu algum dia. Quem nunca fez um sistema de autenticação de usuários?
É para isso que o DDD serve. Para projetar aplicações.
Nesta etapa de projeto (ou re-projeto) das aplicações que o DDD entra. Com a sua metodologia e forma de gerenciar as histórias — e não apenas os dados — dos usuário, o DDD permite criar aplicações reutilizáveis, com baixa dependência e que podem ser escritas paralelamente. Cada equipe escreve um Domínio que, mais tarde, serão integrados por meio de serviços, interfaces e por aí vai.
Por isso DDD utiliza padrões de projeto, boas práticas de programação, integra o arcabouço de metodologias ágeis, abusa da diversidade de padrões de arquitetura de software mas não pode ser resumido a nenhuma dessas coisas. DDD é a música que faz com que todas essas metodologias dancem juntos no mesmo passo.
Por fim, se você deseja desenhar um pequeno framework de persistência, que tal estudar um ORM ou aprender sobre repositórios? Se você quer desenhar aplicações robustas e reutilizáveis, aprenda DDD.
Até logo!