Há alguns meses tive o privilégio de assistir à uma sessão de palestras de um dos meus autores favoritos: Martin Fowler. O tema era sobre padrões arquiteturais para desenvolvimento, distribuição e operação de aplicações, alguns pouco conhecidos, mas muito úteis.
Vou escrever uma série de 3 artigos falando sobre alguns dos padrões que considero mais interessantes. Vamos ao primeiro!
Muitos desenvolvedores enfrentam grandes dificuldades em trabalhar com JPA (Java Persistence API). Vejo que a maioria dessas dificuldades tem raiz na falta de compreensão de certos detalhes do funcionamento do JPA.
Analisarei neste artigo um caso que gera muita confusão, que é o uso do método merge().
Domain-Driven Design ou Projeto Orientado ao Domínio é um padrão de modelagem de software orientado a objetos que procura reforçar conceitos e boas práticas relacionadas à Orientação a Objetos.
Isso vem em contrapartida ao uso comum do Data-Driven Design ou Projeto Orientado a Dados, que a maioria dos desenvolvedores usa sem mesmo ter consciência disso.
Já ouvi várias vezes que os dados são a coisa mais importante em uma empresa, logo a modelagem deve sempre começar pensando-se no banco de dados. Esta é a abordagem algumas vezes chamada de database first, ou “banco de dados em primeiro lugar”.
Não é nada incomum desenvolvedores .Net, Java e C++ começarem um sistema estabelecendo os tipos que eles vão usar e o relacionamento entre eles, como se estivessem criando um Modelo Entidade-Relacionamento (MER). Esses tipos geralmente são objetos “burros”, com getters e setters, representando nada mais, nada menos, que uma tabela do banco de dados.
O problema com essa abordagem é que ela não faz bom uso dos recursos da Orientação a Objetos. Muitos acham que getters e setters são o auge do encapsulamento, mas na prática esses métodos permitem ao usuário recuperar e alterar todos os atributos. Não há ganho algum, a não ser muito código desnecessário.
Enfim, muita gente acha que está usando OO, mas as classes poderiam ser facilmente substituídas por registros ou estruturas de dados mais simples, de acordo com a linguagem utilizada.
Se você consegue ler em Inglês, uma discussão interessante sobre isso está no artigo Dance you Imps!, escrito por Rebert Martin e também conhecido como Uncle Bob.
A ideia inicial do DDD é voltar à uma modelagem OO mais pura, por assim dizer.
Devemos esquecer de como os dados são persistidos e nos preocupar em como representar melhor as necessidades de negócio em classes e comportamentos (métodos). Esta é uma abordam também conhecida como como code first, ou “código em primeiro lugar”.
Isso significa que em DDD um Cliente pode não ter um setter para os seus atributos comuns, mas pode ter métodos com lógica de negócio que neste domínio de negócio pertencem ao cliente, como void associarNovoCartao(Cartao) ou Conta recuperarInformacoesConta().
Em resumo, as classes modeladas e os seus métodos deveriam representar o negócio da empresa, usando inclusive a mesma nomenclatura. A persistência dos dados é colocada em segundo plano, sendo apenas uma camada complementar.
DDD não é uma solução para tudo. A maioria dos sistemas possui uma boa parte composta por cadastros básicos (CRUD) e pelo menos nessa parte não há necessidade de um modelo elaborado de dados.
O DDD deve ajudar na modelagem das classes mais importantes e mais centrais do sistema de forma e diminuir a complexidade e ajudar na manutenção das mesmas, afinal este é o objetivo dos princípios de orientação a objetos.
Rotinas de integração que recebem ou disponibilizam dados para outros sistemas não devem ser “inteligentes”.
Muitos desenvolvedores acabam modelando suas classes de negócios tentando resolver as questões internas do sistema e, ao mesmo tempo, pensando em como essas classes serão expostas para outros sistemas.
Padrões como DTO (Data Transfer Object) que usam objetos “burros” são mais adequados para isso.
O DDD não tenta resolver todos os problemas de todas as camadas de um sistema.
Seu foco é na modelagem das entidades principais de negócio usando a linguagem adequada daquele domínio para facilitar a manutenção, extensão e entendimento.
Particularmente, eu não seguiria à risca o padrão, até porque existem inúmeros padrões e variações de modelagem OO.
Porém, é sempre importante estudar e entender os princípios por detrás desses padrões para, dessa forma, aplicar o que funciona melhor para cada situação.
Nota: escrevi termos como domain-driven com hífen, pois quando duas ou mais palavras formam um adjetivo composto no Inglês elas geralmente devem ser “ligadas”. No caso, domain-driven é um adjetivo de design. (Referência)
Acompanhe minhas respostas no Stack Overflow em Português.
O blog State of the Art de Luiz Ricardo é licenciado sob uma Licença Creative Commons. Copie, compartihe e modifique, apenas cite a fonte.
