Design orientado a domínio e interação entre domínios

Eu sou um novato em DDD, mas estou lendo tudo o que posso colocar em minhas mãos para ferver e destilar meus conhecimentos.

Me deparei com esta pergunta DDD, e uma das respostas me intrigou.

Contextos e domínios vinculados por DDD?

Em uma das respostas, o pôster mostra o exemplo de um sistema de comércio eletrônico com produtos em pelo menos dois domínios:

1) Catálogo de produtos 2) Gerenciamento de estoque

Tudo bem, tudo faz sentido, ou seja, no seu front end de comércio eletrônico, você está interessado em exibir as informações do produto e não em gerenciamento de inventário.

MAS. Você pode exibir o nível de inventário na página da Web ou exibir o número de edição do inventário em estoque (imagine que seu inventário seja livros, revistas etc.). Essas informações são do domínio Inventário.

Então, como você lidaria com isso? Você iria

a) Carrega os domínios de produto e de inventário agregados? b) Você manteria algumas propriedades em sua entidade de domínio do Produto para número em estoque e edição em estoque e usaria Eventos de Domínio para atualizá-las quando a entidade Inventário for atualizada?

Uma pergunta final. Eu sei que devemos esquecer / ignorar a persistência do domínio e apenas pensar no domínio. Mas, só para pensar nisso, no exemplo acima, teríamos potencialmente 2 tabelas de banco de dados para catálogo e inventário de produtos. Agora, usamos o mesmo identificador neles, pois é o mesmo produto. Ou, podemos usar 1 tabela e 1 linha para os dados e simplesmente mapear os dados relevantes nas propriedades agregadas?

Você pode exibir o nível de inventário na página da Web ou exibir o número de edição do inventário em estoque (imagine que seu inventário seja livros, revistas etc.). Essas informações são do domínio Inventário.

O principal a ser observado neste momento é que você está falando sobre uma exibição, ou seja, o uso de dados obsoletos é aceitável.

Dito isto, você não precisa interagir com os agregados (responsáveis ​​por impedir que alterações violem os invariantes dos negócios), mas com uma representação de uma cópia recente do estado do agregado.

Então, o que eu normalmente esperaria é uma consulta executada no Catálogo de Produtos e outra no Inventário, e algo para compor os dois no DTO que você precisa para dar suporte à exibição.

Carregar os domínios de produto e de inventário?

Então está perto . Não precisamos carregar os agregados, porque não vamos mudar nada. Mas precisamos do estado deles; para que pudéssemos carregar isso. Dito isso, eu normalmente esperaria que os dois domínios estivessem sendo executados em processos diferentes. Portanto, estaríamos chamando os dois, não carregando os dois.

Você manteria algumas propriedades em sua entidade de domínio do Produto para número em estoque e edição em estoque e usaria Eventos de Domínio para atualizá-las quando a entidade Inventário for atualizada?

"Não atravesse as correntes. Seria ruim."

Usando eventos para coordenar informações entre contextos de domínio: ótima idéia. Empurrando conceitos que pertencem a um domínio para outro: o oposto de uma ótima idéia, exceto mais.

Você deseja manter os domínios limpos. Os aplicativos que interagem com os domínios não são tão importantes. Por exemplo, é razoável que o aplicativo Inventory chame um serviço no aplicativo do produto para consultar alguns conceitos específicos do produto para adicionar a uma exibição. Ou vice-versa.

Não sei por que motivo um único aplicativo precisa ser restrito a um único domínio. Enquanto houver uma única fonte de verdade, você poderá distribuir as transações da maneira que desejar.

Mas, só para pensar nisso, no exemplo acima, teríamos potencialmente 2 tabelas de banco de dados para catálogo e inventário de produtos. Agora, usamos o mesmo identificador neles, pois é o mesmo produto.

Essa seria a maneira mais fácil. Em termos maiores, você usa o mesmo identificador porque a entidade do mundo real é a mesma; os dois contextos limitados diferentes modelam essa entidade de maneira diferente, mas o modelo não é a entidade do mundo real.

Quando isso não funcionar, você precisará de algumas consultas para preencher a lacuna. Eu acho que a variação mais comum disso é que a entidade mais nova preserva o id da entidade mais antiga. Você também verá isso em um único BC: os candidatos, quando aprovados, tornam-se clientes. É um agregado diferente (o estado associado a um cliente está sujeito a uma invariante diferente da do candidato); portanto, se sua camada de persistência estiver usando fluxos de eventos, o fluxo para o novo agregado precisará de um identificador diferente. Portanto, haverá um pouco de estado em algum lugar que diga "esse candidato se tornou esse cliente".

Ou, podemos usar 1 tabela e 1 linha para os dados e simplesmente mapear os dados relevantes nas propriedades agregadas?

CARAMBA! Não faça isso. Você está adicionando contenção de transações sem qualquer motivo comercial para isso.

Acho que sua pergunta realmente exige 2 conjuntos ortogonais de opções -

• Você carrega dois objetos e apresenta seus dados juntos ou carrega 1 objeto que contém tudo o que deseja?

• Você usa agregados para exibir coisas ou algo mais?

Se você acredita na abordagem CQRS, os agregados podem não ser a melhor aposta para as leituras. Sempre que você carrega um agregado, seja para exibir ou modificar seus dados, você adiciona simultaneidade e contenção ao seu sistema. Além disso, os agregados são potencialmente mais volumosos e mais lentos do que se você usasse modelos de leitura ad-hoc personalizados para exibição.

A solução a) do seu Q parece sujeita a muitas dessas armadilhas. A opção b) pode ser válida, mas eu a usaria apenas se dados do InventoryManagementBC fossem necessários para impor invariantes ao alterar o Productagregado. É melhor que um agregado contenha todos os dados necessários para verificar suas regras de negócios após a modificação, mas no lado da leitura eles podem ficar em qualquer lugar.

Em relação aos dados, uma recomendação comum é fornecer aos contextos vinculados seu próprio banco de dados (por motivos de implantação e SoC). Você provavelmente terá que usar os mesmos identificadores se quiser combinar produtos entre os dois BCs.

Sobre interações entre BC, você também pode consultar /programming/16713041/communicating-between-two-bounded-contexts-in-ddd

DDD é destinado a aplicativos em que a lógica de negócios é complexa. "imprimir algo" não é uma lógica de negócios complexa. Na verdade, não é uma lógica de negócios.

Se a lógica de negócios em um contexto precisar de algumas informações para lidar adequadamente com alguns casos de uso, essas informações farão parte desse contexto. Portanto, a ideia de que um contexto limitado possa precisar de informações disponíveis em diferentes contextos limitados não faz sentido, porque o contexto limitado possui todas as informações necessárias.

Do meu ponto de vista, existem definições diferentes de "Produto" - todo contexto delimitador possui sua própria definição de domínio "produto":

• No Contexto de Limite de Gerenciamento de Conteúdo, um produto possui uma imagem e um texto de descrição.
• No contexto de limite de estoque, um produto possui quantidades em estoque, vendedor do produto, impede quando o produto estará disponível
• No contexto de preço-caculação-limite, existem regras quanto um produto pode custar por quantidade.

Além disso, eu adicionaria um contexto adicional de delimitação de loja com sua própria definição de produto (uma combinação relevante dos domínios de produto dos outros contextos de delimitação).

Um produto da loja teria "imagem e texto de descrição" do conteúdo e disponibilidade do "inventário", mas não "vendedor do produto" do inventário.

Esse contexto adicional de delimitação de loja depende do conteúdo, do inventário e do preço do contexto de delimitação