Objetos de valor e eventos com consequência

Representar quantidade e identidade do item com tipos específicos pode impedir combinações inválidas antes da alteração do saldo. A utilidade aparece quando o tipo recusa uma quantidade negativa ou distingue depósito de pedido. Criar wrappers para todo campo sem restringir operação alguma apenas acrescenta cerimônia.

Ao aceitar R-1, o sistema pode produzir o fato ReservaAceita, com reserva, item, depósito, quantidade e referência ao pedido. Esse fato tem significado no contexto de estoque. O contexto de pedidos decide como traduzi-lo para seu estado, sem compartilhar o objeto inteiro de saldo.

No ensaio de 2011, segunda parte de Effective Aggregate Design, Vernon discute referências entre agregados e consistência eventual, incluindo recuperação de falhas. Aplicando essa preocupação aqui, um evento criado em memória e perdido após a gravação não informa pedidos. Um mecanismo como outbox precisa registrar a intenção de publicação junto à aceitação e depois entregar com repetição controlada.

Outbox é uma opção deste exercício, não garantia automática de entrega única. O consumidor deve reconhecer mensagens repetidas e aplicar sua transição com proteção apropriada. Entre os contextos, não existe uma transação fictícia só porque ambos usam o mesmo nome de evento.

Consistência eventual precisa de experiência e recuperação

Depois da reserva, o pedido pode ficar temporariamente aguardando confirmação. A interface deve distinguir esse estado de uma compra concluída. Um timeout não informa, sozinho, se o estoque confirmou ou recusou. Ofereça consulta pelo identificador do comando ou da reserva para recuperar uma resposta perdida.

A política também precisa determinar quando R-1 expira e como libera a unidade. Expiração e confirmação de consumo podem disputar a mesma reserva; o estado terminal deve impedir liberar duas vezes ou consumir depois de expirar sem nova decisão. Resolver apenas a criação da reserva deixa metade do ciclo descoberta.

Defina responsável por pendências, tentativas limitadas e reconciliação. Se pagamento acontecer após expiração, alguém precisa decidir entre nova reserva, estorno ou atendimento. A consistência eventual aumenta espaço para processos intermediários; sua adoção precisa comprar uma vantagem suficiente para sustentar esse trabalho.

Agregados grandes e pequenos também custam

Colocar estoque, pedidos, clientes e pagamentos no mesmo agregado faria alterações sem relação disputar uma fronteira. A navegação conveniente do ORM pode esconder carregamento excessivo e concorrência desnecessária. Pergunte qual invariante exige cada elemento antes de incluí-lo.

O extremo oposto também falha: separar cada linha em um agregado pode espalhar a própria regra de disponibilidade por gravações independentes. Pequeno é uma direção de projeto, não um objetivo que supera o contrato. Uma última unidade muito disputada continua exigindo arbitragem, mesmo com uma fronteira bem escolhida.

Um carrinho com dois itens acrescenta outra pergunta: pode reservar o primeiro se o segundo estiver indisponível? Se a política exige tudo ou nada, o exemplo de um único saldo não basta. É preciso negociar reserva parcial, compensação ou outra fronteira transacional. Adicionar um identificador de carrinho aos comandos não cria essa garantia. Registre a decisão antes de prometer confirmação integral na interface. Uma reserva local válida ainda pode contrariar a expectativa sobre a compra completa.

Também evite carregar um histórico ilimitado de reservas no saldo. A implementação precisa planejar registros ativos, auditoria e consultas sem perder as garantias de liberação. Isso pede análise do acesso aos dados; o diagrama do agregado não resolve volume, índices ou contenção de um item popular.

Como verificar sem confundir exemplo com evidência

Um teste unitário pode verificar quantidade inválida e disponibilidade insuficiente. Para a tabela acima, use também o armazenamento real: force duas transações a ler a versão 7, permita a primeira confirmação e verifique a rejeição da segunda. Confirme que o saldo final tem apenas uma unidade reservada.

Acrescente dois comandos iguais concorrentes, repetição após timeout e reutilização da chave com conteúdo diferente. Simule falha antes da confirmação e entre confirmação e publicação. Verifique saldo, resultado registrado e retomada do envio. As expectativas precisam sobreviver ao isolamento e às restrições efetivamente configuradas no banco.

Nenhum desses testes foi executado por esta resenha, que apresenta um contrato de exercício. Uma simulação sequencial em memória ajudaria a entender o modelo, mas não demonstraria a propriedade concorrente do armazenamento. Essa diferença deve permanecer visível na documentação da implementação.

Pontos fortes, limites e público indicado

Recomendo o livro para quem conhece a proposta de Evans e já trabalha com persistência e transações. Ele ajuda a transformar nomes de padrões em perguntas verificáveis. O estudo de um domínio contínuo oferece contexto para conectar decisões, sem reduzir tudo a pequenos exemplos independentes.

A edição exige adaptação ao ambiente atual. Seus exemplos Java não devem virar uma obrigação de reproduzir hierarquias, frameworks ou mapeamentos. O modelo de domínio precisa servir às regras; o ORM atende à persistência. Quando a conveniência de um define silenciosamente a fronteira do outro, a modelagem perdeu sua justificativa.

Para operações CRUD com regras simples, uma transação direta e validações claras podem bastar. Adie a adoção extensa se não há problema de linguagem ou consistência que a justifique. Uma equipe sem capacidade de operar reprocessamento também deve considerar cuidadosamente o custo de introduzir integração assíncrona.

Leituras complementares e veredito

Evans ajuda a investigar significado e contexto. Clean Architecture complementa a separação de dependências. DDIA aprofunda mecanismos de dados e concorrência. Nenhum desenho de camadas escolhe sozinho a invariante comercial; nenhum nome de agregado substitui a garantia do armazenamento.

Leia estratégia antes de transportar os padrões táticos para um projeto. Depois escolha uma invariante, escreva estados e comandos como os da tabela e examine a transação correspondente. Discuta falhas e recuperação com a equipe que operará o sistema. Esse é um plano de estudo, sem promessa de redesenhar toda a aplicação.

O motivo para recomendar Vernon é essa aproximação entre compromisso comercial e implementação. Você aproveitou a leitura quando consegue explicar o que permanece consistente na confirmação, o que pode atrasar e como o sistema retoma trabalho interrompido. A quantidade de classes com nomes de DDD é uma medida muito menos útil.