Notas sobre o livro Domain-Driven Design

Apresento aqui algumas notas de leitura sobre o livro "Domain Driven Design: Atacando as Complexidades no Coração do Software", de Eric Evans. O DDD, design dirigido pelo domínio, é uma abordagem de desenvolvimento de software voltado para domínios complexos. No DDD, o software possui uma camada baseada em um modelo rico do domínio, sendo essa camada isolada dos aspectos mais técnicos do sistema. Conjuntamente com os princípios SOLID, padrões de projetos, escrita de código limpo e desenvolvimento dirigido por testes, considero o DDD uma das grande práticas para que o desenvolvedor faça um uso mais correto e proveitoso do paradigma de orientação a objetos. Os objetivos desse documento são:

  •     Ser um exercício pessoal de fixação e assimilação de minha leitura do livro.
  •     Ser uma referência rápida sobre DDD conforma a visão de Eric Evans.
  •     Fornecer uma visão geral sobre o livro Domain Driven Design para outras pessoas.

Acredito que a leitura desse documento de apenas 13 páginas seja uma boa para quem queira ter uma rápida ideia sobre o que trata o livro de Eric Evans (que, aliás, possui 528 páginas).

Na seção "6. Entidades e suas regras de negócio" apresento uma polêmica envolvendo a modelagem baseada em DDD. Em especial sobre essa seção 6, eu gostaria de ouvir seu comentário.

Texto disponível em: https://github.com/leonardofl/ddd/raw/master/ddd.pdf.

Leonardo Leite

3 comments

19
ago

Parabéns pelo texto!

Devemos buscar sempre um equilíbrio! Como você disse em sua seção 6, um modelo anêmico é algo ruim. Existem várias formas de driblar dependências indesejadas de uma entidade, seja injetando uma implementação de uma interface ou até passando ela como parâmetro. De qualquer forma, acho que a lógica de entidades não deva depender de infraestrutura (como acesso a dados).

24
ago

Eu tinha entendido uma coisa, mas quando reli, pareceu outra, nesse caso, existe as regras de negocio do modelo de dominio e os serviços para persistir o banco(CRUD).
No caso, do Django ou Rails, por exemplo, então, além do comportamento de Pessoa.buscar e Pessoa.criar, teria Pessoa.validar, Pessoa.calculaTempo?
ai nesse caso, no modelo anemico é extraido para outra classe o CRUD e no não anemico são extraidas as regras de negocio?
Acho que a arquitetura dos pacotes/modulos, influencia bastante o modelo. Se for numa arquitetura separada em serviços com servicos.dao.beans.Pessoa servicos.dao.beans.Empresa eu imagino que a regras de negocio não estaria nessas classes porque deixa claro que seria um servico do dao. Mas se fosse com dominio, empresa.vendas.Pessoa, eu imagino que a Classe Pessoa teria regra de negocio de pessoas em relacao a vendas e as regras de banco estaria em outro lugar. Se o que eu disse estiver ok, acho que depende bastante se for planejada desde de o inicio em cima de serviços ou do dominio

25
ago

http://mortslikeus.blogspot.com.br/2009/01/active-record-and-ddd.html

https://social.msdn.microsoft.com/Forums/en-US/51ccf4a6-ee5d-4b3e-8b00-8...

Esses são alguns links que sugerem que Active Record e DDD são abordagens incompatíveis e que DDD deve ser usado para projetos com domínios mais complexos, enquanto que Active Record deve ser utilizado para sistemas mais simples baseados em dados.

No entanto, me pergunto se algum programador de Rails ou Django teria coragem de abandonar as comodidades do Active Record?

 

Comentar