DDD - O modelo de domínio anêmico é um antipadrão? Devemos usar modelos de domínio sofisticados? [fechadas]

O modelo de domínio anêmico foi criticado há muito tempo por Evans e Fowler , uma vez que aparentemente contraria princípios orientados a objetos etc. A comunidade DDD está claramente alinhada com essas afirmações.

No entanto, nos últimos anos, houve vozes discordantes alegando que não é um antipadrão e que é um exemplo de seguir os princípios do SOLID.

Trabalho há muitos anos usando o Spring Framework. Todo projeto em toda empresa sempre teve uma camada de serviço contendo a lógica de negócios, usando repositórios que operam em modelos anêmicos (entidades JPA). Além disso, a maioria das amostras, mesmo as oficiais dos caras da Spring, mostra esse modo de trabalhar.

Minhas perguntas são: o modelo de domínio anêmico ainda é considerado um antipadrão? Todos nós fizemos coisas erradas (em relação ao DDD)? Você não acha que ter modelos Rich Domain viola os princípios do SOLID?

O ADM é um bom padrão para uma solução de serviços distribuídos, como microsserviços. Ele se encaixa em muitos dos casos de negócios baseados na Web de hoje.

Considere se temos um objeto Domínio do Pedido. Com uma abordagem OOP, adicionaríamos Order.Purchase () Order.Cancel () etc. Funcionaria bem em um aplicativo de desktop, onde mantemos pedidos na memória e fazemos várias coisas na mesma instância.

Mas se tivermos um sistema distribuído, com programas que apenas uma coisa, ou seja, acessar uma lista de pedidos e comprar cada um por vez, ou obter uma lista de pedidos e cancelar cada um por vez, ter os dois Métodos no mesmo objeto não fará com que sentido. Teríamos que ter dois domínios ou contextos vinculados:

PurchaseSystemOrder.Purchase()

e

CancelSystemOrder.Cancel();

A única coisa que esses objetos compartilhariam seria a estrutura de dados das propriedades.

À medida que você adiciona mais e mais microsserviços, você acaba com dezenas de tipos de pedidos. Não faz mais sentido falar sobre uma Ordem como um objeto de Domínio, mesmo que seja a mesma ordem conceitual que está sendo processada por todos esses sistemas.

Faz muito mais sentido ter um modelo anêmico, Order, que apenas encapsula apenas os dados e renomeia seus serviços de acordo:

PurchaseService.Purchase(Order order)

Agora podemos falar sobre o Order novamente e podemos adicionar quaisquer novos serviços que pensamos em processar, sem afetar os outros serviços atualmente implantados.

Fowler e Co vêm de um sistema monolítico, em seu mundo uma abordagem ADM significaria um único aplicativo com todos esses serviços separados instanciados na memória e o OrderDTO sendo repassado e mutado. Isso seria muito pior do que colocar os métodos em um modelo rico de pedidos.

Porém, em um sistema distribuído, existem muitos programas, cada um requer apenas um método Order e o executa em vários pedidos, carregando cada um, executando o método e depois descartando-o. Requer apenas um único serviço e um fluxo de objetos de dados.

Preencher um modelo completo por completo, preocupar-se com os requisitos e dependências de todos os Métodos apenas para chamar um único e depois descartar o objeto quase imediatamente é inútil.

Além disso, uma alteração em um único método exigiria a atualização de todos os componentes distribuídos, pois todos eles dependem do Modelo Rico para sua lógica.

Não tenho espaço na (s) minha (s) base (s) de código para itens que não precisam

O SOLID e o DDD são ortogonais entre si, o que significa que eles estão realmente indo em direções diferentes um do outro. Você não deve dizer que um está acostumado à exclusão do outro, pois eles podem e provavelmente devem existir juntos na mesma base de código.

Os modelos de domínio anêmico só se tornam um antipadrão quando o domínio do problema tem muito comportamento e você tem centenas de métodos de serviço com muitas lógicas ou dependências de cópia colada, onde os métodos da camada de serviço precisam chamar outros métodos da camada de serviço para fazer qualquer coisa.

O DDD é um excelente paradigma para microsserviços devido ao conceito de contexto limitado .

Cuidado com a tentação de ver o código de infraestrutura como parte do seu domínio. Código de infraestrutura é qualquer coisa que você não tenha escrito ou que esteja acoplado a uma estrutura ou biblioteca que interaja com um sistema de terceiros. Conexões com banco de dados, mala direta SMTP, bibliotecas ORM, tempos de execução do servidor de aplicativos, tudo isso é infraestrutura e você não deve incluir ou depender dela em seu domínio, se puder evitá-la.

Os princípios do SOLID são um conjunto de conceitos de OOP de uso geral que você pode usar para criar um melhor código de OOP. Você pode escrever uma boa base de código DDD usando-as.

Um domínio rico é bom quando bem executado. Um pesadelo quando não. Um domínio anêmico é sempre ruim. Mas é um tipo familiar e confortável de ruim.

Se um domínio anêmico é tudo o que você deseja, escolheu o idioma errado quando escolheu um idioma de uso geral. Os idiomas de quarta geração se especializam em um uso específico. Se a anemia for boa o suficiente, sua vida teria facilitado sua vida.

Muitas estruturas abrem caminho no espaço da linguagem até que você não possa mais anunciar o trabalho como um trabalho em java. É um trabalho Java / Spring. O que eles estão fazendo, além de fazer você depender deles, é transformar uma linguagem de propósito geral em uma forma bastarda de uma linguagem de quarta geração.

Essa é uma prática recomendada ou antipadrão? Bem, seu chefe se preocupa principalmente se você pode contratar pessoas para trabalhar na base de código. Portanto, se tivermos que fingir que estamos usando uma linguagem de uso geral para contratar pessoas, o faremos.

Se você está bem com isso, tudo bem. Você certamente não é o único.

Mas não me diga que é assim que deve ser. Não me diga que está fazendo algo por mim mais do que está. Eu sei viver sem isso. Eu sei como empurrar para fora, então apenas algumas coisas dependem disso. Se você está me pedindo para desistir e deixar que tudo assuma tudo, porque lutar é difícil demais, sim, acho que isso é ruim.

Não tenho espaço na minha base de código para coisas que não precisam.

Quanto ao SOLID e aos outros princípios de design, posso seguir em grande parte aqueles mesmo em um domínio anêmico. Não segui-los causa um tipo diferente de problema.