Como definir claramente os limites de um contexto delimitado

Depois de mais ou menos um mês lendo e pesquisando DDD, decidi iniciar meu próprio projeto e criei DDD com esses contextos limitados>

• Clientes
• Produtos
• Encomendas
• Faturamento

Cada contexto delimitado possui API de descanso como uma camada de apresentação, camada de domínio, camada persistente.

Até agora, o código está funcionando perfeitamente, mas, vindo de um mundo monolítico, ainda estou tentando descobrir o seguinte:

• quando eu quiser criar um novo cliente, emitir uma nova fatura, criar um novo pedido que eu queira, por exemplo, acessar a lista de países. Eu:

a) crie uma lista de países em cada BC

b) crie uma API de países BC -> e use-a para obter uma lista dos países disponíveis

c) use uma API de terceiros e extraia dados através da camada anti-corrupção em cada BC

• ao integrar com a API de terceiros usando uma camada anticorrupção ou uma camada adaptadora, quais dados devem ser incluídos no meu modelo de domínio? Por exemplo, se eu quiser integrar uma API do zendesk a um Client BC. Preciso apenas de um ticketID no meu domínio ou tenho que extrair todos os dados do Zendesk que desejo acessar e usar em um Client BC?

Se meu aplicativo MVC está realmente obtendo dados das APIs (camadas de apresentação dos meus contextos limitados), acho muito difícil definir claramente os limites de cada BC. Isso significa que um BC projetado adequadamente serviria a um único controlador MVC sem a necessidade de consumir APIs adicionais?

Se seus diferentes contextos limitados entenderem o significado / objetivo de um país de maneira diferente, será necessário modelá-lo de maneira diferente em cada um. No entanto, se estivermos falando simplesmente de dados de referência de códigos e nomes ISO, acredito que seja bastante justo e padrão guardá-lo onde for conveniente e torná-lo acessível a todas as partes interessadas. Por exemplo: um banco de dados, um arquivo de configuração, um serviço da web etc.

Eu também queria olhar um pouco para o seu modelo. As peças que você listou podem muito bem ser "entidades" em um "contexto limitado", dependendo da estrutura da empresa. Os BCs frequentemente acabam sendo definidos em torno de diferentes áreas / departamentos / equipes, uma vez que esse é frequentemente o limite natural entre as "línguas onipresentes". Por exemplo, em vez de Vendas / Produtos / Pedidos, eu esperaria que os BCs estivessem na linha de Vendas / Fabricação / Armazenagem.

Dentro desses BCs, você não se concentra nos substantivos. Você se concentra nos casos de uso e cria modelos dos substantivos que podem atender aos casos de uso. Os métodos em uma "raiz agregada" executam casos de uso e fazem as alterações apropriadas nos modelos relacionados.

... todos os modelos estão errados, mas alguns são úteis.

Também tenha em mente que cada BC pode usar um sistema ou arquitetura totalmente diferente. Um determinado BC pode não merecer o uso de "componentes de software DDD", e a maioria deles provavelmente não. DDD é menos sobre componentes de software prescritivos e mais sobre o processo de criação de software. O objetivo é focar na compreensão dos contextos limitados da empresa, mapear as linguagens onipresentes de cada contexto e modelar o código para esse contexto usando sua linguagem onipresente. Dessa forma, quando você interage com as partes interessadas e se refere ao código, parece-lhes que você está falando em termos comerciais que eles entendem. E reconhecendo que a mesma palavra tem significados diferentes em diferentes BCs.

Existem padrões específicos trazidos pelo DDD (por exemplo, repositório, camadas específicas, etc.) que são meios para atingir um fim. Mas não é garantido que esses padrões sejam os melhores para todos os casos, mesmo dentro do DDD. Assim como o DDD não é "a" resposta para todos os projetos. Você só precisa fazer o que sua análise sugere é a coisa mais prática a fazer.

De suas perguntas, acho que você não entende o contexto limitado. Você pode reler o capítulo 14 do livro azul .

Tentando responder de maneira geral - é preciso ter cuidado ao compartilhar conceitos entre dois contextos limitados diferentes. Afinal, parte da razão da existência do limite é que a linguagem onipresente muda. Assumir que os mesmos dados (e a mesma representação) de uma entidade podem ser usados ​​em ambos os contextos é ingênuo - pode estar certo, pode estar errado, mas não há um bom caminho para nós de fora, sem acesso aos especialistas em domínio, a julgar.

Por exemplo, no domínio do cliente, "país" pode estar relacionado à residência ou cidadania. No faturamento, isso pode estar relacionado às taxas de câmbio. Em alguns desses domínios, pode ser necessário se preocupar com tarifas e similares.

Uma segunda pergunta que você precisa fazer é qual dos seus modelos é o livro de registro dos dados "compartilhados". No caso de "país", a resposta certa é provavelmente que nenhum deles é! A topologia geopolítica não é controlada pelo seu modelo.

O que deve acontecer nos seus modelos de domínio quando um país é ocupado por uma potência estrangeira?

Tenha em mente; muitos de nós estão acostumados a pensar sobre a estrutura de dados; qual é a relação entre um dado e outro. E isso é ótimo quando você está considerando relatórios e tentando garantir que todos os dados necessários sejam coletados por sua solução. Mas os modelos de domínio não são apenas sobre estrutura, mas sobre mudança. Você também deve colocar sua atenção nessa parte e entender como os dados restringem as alterações (e como essas restrições variam de um contexto limitado para o seguinte).

Os conceitos mencionados (clientes, produtos, pedidos, cobrança) são normalmente representados em um único modelo de domínio e, portanto, em um contexto vinculado. Eu sugiro que você esteja entendendo esses conceitos incorretamente.

Minha opinião sobre esse assunto é definir o contexto limitado usando um mapeamento de capacidade de negócios ou outras técnicas semelhantes, como a análise da cadeia de valor. Tudo se resume às seguintes etapas:

1. Defina as responsabilidades de nível superior ou os recursos de negócios do seu sistema. A melhor maneira de fazer isso, acho, é conjurar etapas que sua empresa segue para obter um valor comercial. Os limites lógicos que você cria são seus serviços de negócios ou, se você preferir, contextos limitados.
2. Mergulhe mais fundo em cada serviço.
3. Identifique as comunicações entre seus serviços juntamente com os dois primeiros pontos.

Portanto, o foco inicial está em como sua empresa opera.

Algumas dicas práticas:

1. Se um de seus contextos / serviços / etc precisar de outros dados de contexto, provavelmente seus limites estão errados.
2. A maneira altamente desejável de comunicação de contexto é baseada em eventos. Essa é a chave para escalabilidade e confiabilidade. Se você precisar de comunicação síncrona, provavelmente os limites estão errados novamente. Além disso, a comunicação síncrona matará seu sistema.
3. Seu domínio é mais consistente do que você imagina. Assim como todo mundo. Não tente tornar tudo 100% consistente. Não há sentido prático nisso.
4. Os contextos não precisam ser orquestrados. Eles são independentes. Como humanos.

Com essa abordagem, você acaba com serviços altamente autônomos, sustentáveis ​​e confiáveis. Você pode querer verificar um exemplo de definição de limites de contexto.