DDD: DTO vs Entity

Utilizando DDD em meus projetos, fiquei tão satisfeito com os resultados que resolvi compartilhar a experiência aqui no meu blog.

O primeiro paradigma que eu tive que me defrontar foi em relação ao “Entity”. Em outros sistemas, eu costumava utilizar uma classe exatamente como uma estrutura de tabela do banco de dados (http://martinfowler.com/eaaCatalog/associationTableMapping.html) e, em uma classe separada, colocava as regras de negócio. Ex.: Cliente (somente com Gets e Sets) e BLCliente (com o CRUD + Regras de Negócio, por exemplo calcular crédito). Também é conhecida como “Arquitetura BOLOVO”.

Quando eu comecei a ler sobre os princípios no qual o DDD foi concebido, me vieram à mente as aulas básicas de OO que você aprende na faculdade. Imagine que você tenha uma classe Carro, nela contém as propriedades referentes à quantidade de portas, cor, placa, etc. Você também colocaria o método andar() certo? Mas no modelo que eu utilizava se em vez da classe Cliente fosse a classe Carro, o modelo ficaria da seguinte forma: Carro (Gets e Sets) BLCarro (método andar()). Meio estranho isso você não concorda?
Você não precisa de um outro objeto para fazer o seu carro andar, se você simplesmente ligar o seu carro e acelerar o carro vai andar.

Se você reparar com cuidado o exemplo que eu dei logo no começo do tópico em relação a classe Cliente, você vai reparar que existe um procedimento calcular crédito dentro da classe BLCliente. No modelo que eu trabalhava se precisa-se saber o crédito de um cliente provavelmente este método estaria dentro da classe BLCliente, mas será que, como exemplo de cartão de crédito, o cliente sabe o quanto ele tem de crédito? Se você analisar no mundo real, o cliente geralmente só conhece ou precisa saber o seu crédito quando efetua uma compra ou quando pede de alguma forma o extrato para a operadora de cartão, certo? Por mais organizado e controlado que o cliente possa ser a operadora de cartão sempre deverá ter disponíveis meios para informar o cliente do seu crédito sempre que ele precisar.

Essa é uma outra característica marcante do DDD, as classes e métodos têm que estar o mais relacionado possível com a linguagem do negócio e para isso o DDD utiliza o Ubiquitous Language, fazer com que o sistema e profissionais com ele envolvidos falem a língua do cliente.

Bom, depois de resolver o problema das minhas classes anêmicas comecei a me deparar com o problema da persistência. As minhas BL’s eram responsáveis em chamar as minhas DAO’s para persistir os meus DTO’s, como fazer isso no DDD? Poderia fazer com que a minha entidade se persistisse no banco de dados, que tal?

Existe um padrão muito conhecido chamado Active Record que trata justamente da entidade de negócio se persistindo no banco de dados, eu não tenho nada contra quem o utiliza mas eu particularmente não costumo usar. Um cliente não se “insere” em algum lugar, certo? Um cliente não se “salva”, só Jesus salva, correto? Por esses motivos não estava querendo colocar essa responsabilidade na própria entidade de negócio. Eu resolvido esse problema utilizando um padrão também abordado no DDD chamado Repository Pattern, através dele é possível tirar a responsabilidade de persistência das entidades de negócio.

Mesmo depois de “organizar a casa“ em relação as minhas entidades de negócio, não significa que o padrão DTO não é útil, na verdade eu continuo utilizando o DTO, mas exercendo o papel no qual ele foi concebido.

No projeto que eu utilizei DDD a interface foi desenvolvida com o front-end em Adobe Flex e ela contém as classes específicas para comunicação entre back-end em .Net e o front-end. Ex.: Se a minha entidade de negócio Cliente tivesse um método ObterCredito() com todo o processo de negócio para obter o crédito do cliente, o meu DTO Cliente já teria a propriedade Credito, portanto, o meu front-end já teria essa informação calculada.

Nos próximos posts eu estarei publicando trechos de um projeto que estou criando somente para fins de estudo do DDD e estarei discutindo passo-a-passo os conceitos da disciplina aplicada no projeto, mas já espero com esse tópico aguçar a sua vontade de conhecer mais a fundo o DDD.

Algumas fontes de estudo:
http://domaindrivendesign.org/
http://www.infoq.com/minibooks/domain-driven-design-quickly
http://weblogs.asp.net/arturtrosin/archive/2009/02/09/domain-driven-design-learning.aspx