Cuidado com Domain-Driven Design

Em tecnologia existe um fenômeno interessante. Existe um problema qualquer. Alguém resolve o problema de um modo e as pessoas começam a usar este modo. O detalhe é que as pessoas não param para ler as fundamentações técnicas, a coisa vira um grande grupo de achismo. Aí surge outra solução que é mais eficiente e utilizada por uns poucos que tentam convencer os outros. Quando finalmente as pessoas se convencem elas repetem o ciclo, não estudando a fundo as bases e caindo no conto do vigário.

Este post no GUJ mostra um claro desvio dos padrões estipulados por Domain-Driven Design. Vamos desmistificar a coisa: DDD é uma forma disciplinada de criar um Domain Model, só isso. O foco da técnica é criar um domínio que “fale a língua” do usuário. Isso não quer dizer que você vá “mapear o mundo real” com objetos, esse não é o objetivo nem da técnica nem de Orientação a Objetos em primeiro lugar.

Passeando pela thread, você pode perceber diversas coisas fora do que é definido em DDD. Os conceitos de Domínio e Contexto confusos. Domínio é o que o programa (seja um exercício de faculdade ou um sistema empresarial) modela, o que ele se propõe a resolver. O modelo que você criou deste domínio (o Domain Model) certamente possui intersecções com modelos criados em outros sistemas, serviços, etc. Neste caso o dividimos em Contextos:

Explicitly define the context within which a model applies. Explicitly set boundaries in terms of team organization, usage within specific parts of the application, and physical manifestations such as code bases and database schemas. Keep the model strictly consistent within these bounds, but don’t be distracted or confused by issues outside.

A analogia do círculo é péssima porque ela foca em uma caixa-preta, que não é um Módulo em Domain-Driven Design. Em DDD um módulo é quase que exatamente como um pacote em Java ou namespace em C#. O Contexto é dividido em Módulos, que agrupam entidades com conceitos em comum. A comunicação entre Contextos e entre Módulos é dada através de diversos padrões e técnicas.

Existe uma confusão também com Value Object. Em DDD um Value Object é um conceito de domínio como qualquer Entidade a diferença é que ele não tem identidade própria. Se eu pegar uma nota de dez reais emprestado de você você não exige que eu te devolva a mesma nota, apenas que devolva uma nota de mesmo valor ou equivalente. Este conceito do “mesmo valor” é o coração do Pattern. O tópico coloca o pobre VO como um TO, mero agrupamento de dados.

A parte da transação também é muito complicada. Desde o início deste século que nós estamos separando estas responsabilidades (autenticação, transações, log, etc.) como conceitos ortogonais. Conceitos ortogonais não devem, quando a tecnologia permite, estar implementados junto com regras de negócio, junto com entidades de domínio. Para isso suamos a AOP expressa por ferramentas como Spring Framework ou EJB (seja 2.1 ou 3.0). Eric Evans fala sobre separação entre domínio e tecnologia:

The domain model is a set of concepts. The “domain layer” is the manifestation of that model and all directly related design elements. The design and implementation of business logic constitute the domain layer. In a MODEL-DRIVEN DESIGN, the software constructs of the domain layer mirror the model concepts.

It is not practical to achieve that correspondence when the domain logic is mixed with other concerns of the program. Isolating the domain implementation is a prerequisite for domain-driven design.

Falar que ActiveRecord não funciona é negar a realidade. Frameworks como Ruby on Rails, Castle e Grails se baseiam nele, não é porque não até até então nenhuma proposta Java de framework que o conceito não funciona. O exemplo dado não representa qualquer problema, já que transações são tratadas em um conceito ortogonal separado, como descrito acima. Se AR se aplica bem ou mal no caso X ou Y, com DDD ou o que for é outro assunto, que aliás já tratamos aqui mais de uma vez.

Interessante que toda a thread teria começado porque o autor original achou que os artigos deste blog não são completos o suficiente. Independente de serem (e não são) ou não, o que eu sempre recomendo éleia a bibliografia. Infelizmente tem (muita) gente que prefere simplesmente ter um pseudo-resumo rápido num fórum. Fazendo uma análise dos pontos que levantei aqui e de outros no texto em questão eu percebo que o autor original em si não teve muito sucesso em aprender os conceitos de Domain-Driven Design porque procurou o meio errado. Outro dia uma thread no mesmo fórum sobre o mesmo tema corria parecido, com uma pessoa fazendo críticas em cima de um modelo usando Repositórios. O problema é que o cidadão em questão nem sequer leu sobre a técnica antes de criticar, nem mesmo no resumo disponível gratuitamente apenas pedia um exemplo como se quatro linhas de código fossem passar 500 páginas de conhecimento. O mundo tem pressa e preguiça, mas até onde isso leva?

5 Responses to “Cuidado com Domain-Driven Design”

  1. Eu acho muito educado o autor desse artigo não identificar os envolvidos no assunto, porem acho que não existe problema se eu me identificar.

    Fui eu que criei o post no GUJ e o artigo acima retrata a perspectiva do autor, porem gostaria de mostrar a minha perspectiva.

    Eu queria muito entender o que era o DDD, o forum serve como meio de discussão e aprendizagem, mas é óbvio que eu ou os demais envolvidos nao vamos aprender todas as técnicas do DDD dessa forma.

    Imagine as mensagens do post como se fosse uma sala de reunião, aonde as pessoas debatem sobre um determinado assunto, logico que não vamos aprender tudo mas a ideia é debater o assunto e é para isso que o forum existe.

    O post faz referencia a dezenas de livros e materiais, e quando se chaga a uma conclusao os envolvidos ficam melhor direcionado para pesquisar sobre o assunto.

    Um exemplo claro é que eu ia comprar um livro de EJB para tentar solucionar o problema do modelo anemico, mas depois eu vi que na verdade nao é bem isso. Hoje eu me sinto em uma posição melhor para tomar decisões e espero que vc leitor tb esteja ;)

    Segue abaixo todos os post, assim nao temos problemas em mostrar uma unica perspectiva
    http://www.guj.com.br/posts/list/62818.java
    http://www.guj.com.br/posts/list/62527.java
    http://www.guj.com.br/posts/list/60916.java

    Durante as discussões as vezes agredimos uns aos outros, isso é muito ruim e eu mesmo cometi esse erro. Eu aprendi com meus próprios erros, espero que o Phillip entenda que nao tenho nada pessoal contra ele e que na verdade ele contribui muito para a comunidade.

  2. Rodrigo Lara says:

    Boa, Ronildo. Eu acho que o Philip foi exagerado (eu diria infeliz, mas ele ia ficar puto comigo) com relação a reação da sua comentário mais o que rolou foi que você queria coisa demais pra um artigo só, um blog só, etcetcetc
    Esse cara ai (o outro nao identificavel) nao foi o mesmo que teimou por paginas que java tinha ponteiro, ate que o Gosling deu uma porrada nele? http://www.guj.com.br/posts/list/61217.java
    Quanto ao artigo seu em si eu discordo. Quando tinha EJB a própria SUN dizia que para usar JAVA você usava EJB. Com DDD, OO e etc. existem livros e artigos que um tipo de gente simplesmente não dá a menor pelota, lembra de um conhecido nosso que dizia que para sbaer tudo que um livro tem ele lia soh o primeiro e o ultimo capitulo? Eh por ai. Acotnece que tem gente assim, nao todos. Muitos nao leem porque nao sabem o que ler, acho que foi o que rolou com o Ronildo.

    Peace

  3. [...] - Domain Driven Design : DDD, Shoes & Shoes, e tem uma matéria muito legal do Sérgio Lopes na Mundo Java 3 (que eu não tenho direito de [...]

  4. [...] do que isso é ter ótimos conhecimentos sobre desenvolvimento ágil e ser capaz de trabalhar com Domain Driven Design, entender um pouquinho só sobre Continuos Integration e a sua importância e tudo mais que puder [...]

  5. [...] Philip Calçado, provavelmente baseado no exemplo de Fowler, dá um ótimo exemplo de VO falando do objeto Dinheiro. Um dinheiro, supomos aqui, Reais, possui um valor: dois, cinco, dez, vinte, cinqüenta, etc… [...]