Contextos e domínios vinculados por DDD?

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).

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.

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,