Um contrato entre modelos precisa dizer mais que nomes

Uma proposta aceita produz uma instrução com estes dados: instructionId=I-81-2, proposalId=P-81, revision=2, accountRef=C-14, amountMinor=10000, currency=BRL. A instrução registra o compromisso comercial usado nesta integração. Ela não afirma que o devedor já foi validado.

A tradução mantida por faturamento resolve accountRef para um devedor e verifica sua habilitação. Se não houver vínculo válido, registra a instrução como pendente e não emite cobrança. Quem opera essa pendência precisa conseguir ver a causa e completar o cadastro; uma falha silenciosa criaria um problema de processo disfarçado de integração.

Fixe invariantes verificáveis. A instructionId permanece estável em reenvios e não pode criar duas obrigações. Reutilizá-la com conteúdo comercial divergente, como outra proposta, revisão, conta, moeda ou valor, constitui conflito para análise; não autoriza sobrescrever a obrigação. A moeda da instrução deve corresponder à moeda admitida para aquela obrigação. O cancelamento comercial posterior precisa de uma operação explícita; não apaga automaticamente um registro financeiro. Na implementação, o registro de deduplicação e a criação da obrigação precisam ser atômicos; o exemplo conceitual não comprova essa propriedade.

Uma alteração da proposta cria outra revisão, mas a política de substituir ou complementar uma obrigação deve ser negociada. O número de revisão sozinho não decide isso. Esses contratos tornam a fronteira discutível: agora é possível pedir exemplos de repetição, alteração e cancelamento antes de escolher eventos, endpoints ou tabelas.

Entidades, valores e agregados a serviço das regras

No nosso modelo de vendas, P-81 mantém sua identidade quando o endereço de contato muda. A decisão de tratá-la como entidade permite perguntar quais transições pertencem à mesma proposta. A conta comercial e o devedor financeiro têm identidades próprias; sua associação exige manutenção, não uma igualdade presumida entre números.

Um valor monetário pode representar quantidade e moeda em conjunto. Dois valores de 10.000 centavos BRL podem ser equivalentes para um cálculo; quantidades em moedas diferentes não são intercambiáveis. Imutabilidade ajuda a evitar que uma alteração em um objeto compartilhado modifique acidentalmente uma proposta já aceita.

Para a proposta e seus itens, experimente uma fronteira de agregado que impeça aceitar itens com moeda incompatível ou modificar preços de uma revisão aceita. Essas são invariantes desta política fictícia. A implementação precisa impedir escrita direta que contorne as operações responsáveis por mantê-las, inclusive em código de manutenção.

Não inclua toda conta, proposta e cobrança em um único agregado apenas porque há relacionamentos. Isso aumentaria o trabalho necessário para alterar qualquer parte e poderia ampliar bloqueios transacionais. A obrigação financeira pode ter sua própria consistência. Entre fronteiras, o exercício precisa de tradução e tratamento de pendências, com custo explícito.

Mapeamento, responsáveis e custo da separação

Desenhe um mapa simples: vendas fornece a instrução; faturamento traduz e decide sobre emissão. Identifique quem aprova o contrato e quem comunica mudanças. Se faturamento não consegue influenciar o formato, terá mais trabalho de adaptação; representar essa dependência vale mais que desenhar caixas simétricas sem responsáveis.

Mantenha testes com os registros do exercício. Verifique que a proposta pode ser aceita sem devedor, que a instrução fica pendente sem vínculo e que duas entregas iguais produzem uma única obrigação. Acrescente o conflito de valor e a revisão posterior. Os casos devem exercitar a implementação real do contrato escolhido.

Essa separação custa código de tradução, rastreamento e reconciliação. Num monólito, chamadas e transações podem simplificar parte do trabalho. Se futuramente houver comunicação assíncrona, falhas e duplicação exigirão garantias operacionais adicionais. Um desenho conceitual não demonstra que a entrega ou a deduplicação funcionam.

Onde o livro é forte e onde a aplicação falha

O mérito é permitir contestar modelos aparentemente naturais. Uma classe chamada Cliente parece inofensiva até carregar regras incompatíveis. Ao acompanhar cenários, você consegue descobrir se faltava um conceito, uma fronteira ou apenas uma regra mal compreendida. Isso oferece uma conversa técnica com consequência comercial.

A leitura exige esforço e adaptação. Exemplos orientados a objetos e código Java refletem o contexto da edição. Seus princípios podem informar outras linguagens, mas reproduzir hierarquias e repositórios mecanicamente não garante boa modelagem. Uma aplicação funcional pode expressar as mesmas distinções com outros mecanismos.

Também considero perigoso reduzir DDD a uma estrutura de pastas. Sem acesso a especialistas ou a exemplos de decisões, os nomes podem apenas organizar suposições. E um especialista isolado pode representar uma parte do processo. Procure divergências entre operação, suporte e área financeira antes de declarar a linguagem resolvida.

Quando recomendo, quando adiaria

Recomendo para quem já desenvolveu software com regras que mudam e consegue discutir testes, persistência e transações. Conhecimento de orientação a objetos ajuda a acompanhar a edição, mas o investimento principal é raciocinar sobre significado e responsabilidade. Um leitor iniciante aproveitará mais ao associar cada conceito a um fluxo concreto.

Para um cadastro administrativo com poucas regras e pouca divergência, um CRUD claro pode ser suficiente. Aplicar agregados complexos a cada tabela pode consumir tempo sem melhorar decisões. Quando o negócio ainda procura seu próprio vocabulário, trate modelos como hipóteses pequenas e revisáveis; não tente congelar toda a organização em um esquema definitivo.

Implementing Domain-Driven Design, de Vaughn Vernon, complementa a discussão de implementação. Clean Architecture ajuda a pensar sobre direção de dependências. Separar infraestrutura não responde, sozinho, se cliente comercial e devedor são o mesmo conceito; essa é a investigação que justifica ler Evans.

Plano de leitura e veredito

Comece pelo trecho de comunicação e linguagem, leve uma palavra ambígua para uma conversa com duas áreas e registre dois cenários conflitantes. Depois estude contexto e mapeamento para testar uma fronteira. Volte aos padrões táticos quando uma regra exigir identidade ou consistência explícita. Essa é minha proposta de estudo, não uma ordem obrigatória do livro.

Implemente uma passagem pequena, como a instrução do exercício, e peça às áreas que expliquem os registros e os casos recusados. Se a implementação obriga alguém a reinterpretar tudo em uma planilha, investigue o que o modelo deixou de representar. Revise o vocabulário conforme novas situações aparecerem.

Minha recomendação é forte para domínios em que mal-entendidos viram código e retrabalho. O resultado desejável é conseguir explicar qual regra pertence a cada modelo, qual compromisso atravessa a fronteira e quem responde por ele. Esse critério é mais útil que contar quantas entidades, serviços ou agregados você introduziu.