Contextos e domínios vinculados por DDD?

16

Eu tenho trabalhado em um aplicativo relativamente complexo com 10 tabelas de banco de dados (agregados, entidades / objetos de valor) e aplicado o DDD. Neste ponto, parece ser basicamente o DDD-Lite, o que significa que existem Serviços de Aplicativo / Domínio, o Modelo de Domínio (Entidades, Objetos de Valor) e Repositórios.

Peguei um livro Implementando DDD e a primeira coisa que ele está mencionando é Contextos e Eventos de Domínio e DDD-Lite e Limitados, faltando como primeiros erros, que são comuns no início do DDD.

Atualmente, tentei organizar o modelo de domínio por relacionamentos agregados e usar espaços de nome para demonstrá-lo.

Não estou conseguindo ver os benefícios / quedas relacionados à separação do projeto Modelo de Domínio em contextos limitados separados (ainda). Talvez isso se torne aparente mais tarde, mas eu gostaria de receber algum feedback da vida real sobre os Contextos vinculados (e possivelmente subdomínios etc., se eles se vincularem a ele).

lko
fonte
Parece-me que a única coisa que define contextos limitados separados é a necessidade de diferenciar linguística e diferenças operacionais associadas, ou seja, é chamado de produto em uma área e produto em outra área, mas são diferentes, então precisamos de dois produtos e ambos podem ' Não esteja no mesmo modelo (mesmo nome, etc.). Então, por que não mudamos os nomes para representar sua semântica sutilmente diferente? Eles poderíamos ter um modelo para governar todos eles. Subdomínios são naturais, mas não estou vendo contextos limitados no momento. Só de pensar em voz alta aqui ...
Ashley Aitken
Eu acho que você já percebeu por que é rentável dividir seu domínio em contextos. Então, o que poderia ser útil agora é a maneira correta de identificá-los, de definir os limites do contexto. Aqui está como eu faço: medium.com/@wrong.about/…
Zapadlo 2/17/17

Respostas:

20

Considere uma empresa que possui alguns departamentos diferentes:

  • Desenvolvimento de software
  • RH
  • Contabilidade

Você pode criar um modelo de usuário que possa representar expressivamente todas essas áreas de negócios? Pense na aparência da entidade Usuário em cada uma. Talvez esteja dividido em três entidades diferentes:

  • Desenvolvedor
  • Empregado
  • Beneficiário

O esforço para instanciar um usuário em cada contexto é consideravelmente diferente. Talvez seja algo assim:

  • novo funcionário (ssn, nome, joindate, data de nascimento, sexo)
  • novo desenvolvedor (funcionário, estação de trabalho, credenciais)
  • novo Beneficiário (funcionário, função)

desculpe o exemplo, é difícil ilustrar com precisão sem um modelo de domínio adequado para fazer referência

Se você usasse uma implementação ingênua e usasse uma única entidade de usuário, ele acabaria sendo um modelo de dados anêmico cheio de getters e setters, porque você não poderia representar completamente o usuário em todo o lugar.

Existem limites claros nos negócios, por isso é útil modelá-los dessa maneira. Um usuário que faz login versus um usuário em um sistema de folha de pagamento versus um usuário que joga um jogo é muito diferente, mesmo que faça parte do mesmo grande sistema.

Pensando de outra maneira - agora você pode criar seu código de gerenciamento de desenvolvedor para ser muito leve e independente do resto do seu sistema. Pode usar tipos mais precisos com menos bagagem para se preocupar. É o passo para criar subsistemas menores que eventualmente podem ser extraídos em seu próprio aplicativo.

Adrian Schneider
fonte
Obrigado pelo exemplo de apoio que ajuda a ilustrar as diferentes necessidades dos 3 aC.
Lko4 /
Não é o modo como estou acostumado a ver esses conceitos: normalmente, um Employeenão é um User, ele tem um User. A Useré simplesmente uma entidade através da qual uma pessoa pode entrar e aceder a uma ou mais aplicações dentro da organização. E um Employeenem sempre tem um User. Além disso, você normalmente não recebe um aplicativo simples para diferentes departamentos; Normalmente, cada departamento tem seus próprios aplicativos, cada um contendo seus próprios modelos de domínio. Portanto, para mim, essa resposta não ajuda a esclarecer a necessidade de ter contextos limitados separados na mesma base de código.
Rogério
@ Rogério sua objeção é realmente um belo exemplo de por que é importante definir corretamente as línguas onipresentes usados dentro de cada contexto limitada :)
MauganRa
Só me pergunto nos casos em que temos um sistema de gerenciamento de clientes, quando telefonamos para consultar nossos pedidos ou cobrança, etc., ficamos em espera enquanto somos transferidos para o departamento apropriado. O conhecimento do domínio de cada departamento entra em jogo - para grande aborrecimento do cliente nesses cenários. Talvez possamos culpar o DDD por forçar a separação entre esses contextos.
Andez 30/10
16

Eu posso te dar outro exemplo. Considere que você tem algum sistema de comércio eletrônico. Você teria produtos lá, no entanto, os produtos farão parte de pelo menos dois domínios diferentes:

  • Catálogo de produtos, onde você mantém a descrição do produto e todos os atributos
  • Inventário, onde você tem nível de estoque do produto

Se você tiver um contexto delimitado para os dois domínios, sua solução poderá rapidamente se tornar uma grande bola de barro, porque você começará a fazer referência cruzada. No final, você não terá mais dois domínios. Seu inventário de produtos será estragado com referências ao catálogo de produtos e vice-versa. Como resultado disso, você não poderá alterar um domínio sem tocar em outro, mesmo sabendo que isso não é necessário. Seus modelos se tornam dependentes um do outro e fortemente acoplados, e dependem de uma maneira ruim - dependendo da implementação.

Se você, no entanto, tiver dois contextos limitados, todas as alterações feitas em um domínio não afetarão o outro assim que você manter seus canais de comunicação limpos. Isso significa que você precisa ter duplicação de dados, mas esse é o menor custo a pagar por aplicativos baseados em componentes com pouco acoplamento. Seus domínios podem conversar entre si usando eventos de domínio. Mesmo que você não planeje ter um aplicativo baseado em SOA no início, poderá escalar até esse nível quando precisar com um esforço relativamente baixo, pois você acabou de alterar o transporte para os eventos do seu domínio, deixando a ideia para trás intacta.

Atualização: Existe uma boa transmissão de habilidades no SkillsMatter, de Eric Evans. Ele faz uma analogia da velha história, quando vários cegos descrevem um elefante a partir de sua perspectiva. Como cada homem pode tocar apenas uma parte do elefante, eles o descrevem como "árvore", "muro", "cobra", "corda". E cada um desses homens está certo em seu contexto. Contexto limitado é onde a linguagem onipresente vive. Fora do contexto, esses termos podem ter um significado completamente diferente, mas dentro do contexto, o idioma é o mesmo em vários domínios. Greg Young sugere fortemente começar a ler o livro azul do capítulo 11, uma vez que os conceitos fundamentais mais importantes são explicados lá. O foco nos padrões táticos no início do livro torna essa abordagem "DDD-light" muito comum,

Alexey Zimarev
fonte
1
+1 por trazer também a duplicação. é um pouco confuso no início ( "estou fazendo isso errado ?!), mas é completamente natural, qualquer em muitos casos, necessário.
Adrian Schneider
Nesse cenário, essas Productclasses compartilham hipoteticamente o mesmo ID (por exemplo, ambas as tabelas BC separadas têm uma chave estrangeira para uma tabela com um único ID do produto)? Talvez ao se comunicar com os Eventos do Domínio eles possam usar esse ID?
LKO
1
Tudo depende de qual armazenamento é escolhido. Não é necessário usar o ID técnico para se referir a vários domínios. Também não é aconselhável fazer comunicação entre contextos.
Alexey Zimarev
1
Parece que é hora de começar o livro azul para fora da prateleira e ler os capítulos posteriores
Markus Pscheidt