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,