Design Orientado a Domínio #6 — Agregados, Fábricas e Repositórios: o ciclo de vida de um objeto

Todo objeto de domínio tem um ciclo de vida — nasce, muda de estado, eventualmente morre ou é arquivado. Este capítulo ataca os dois problemas que esse ciclo de vida traz: manter a integridade do modelo enquanto ele muda, e não deixar a complexidade de gerenciar esse ciclo sobrecarregar o próprio modelo. A resposta são três padrões que se encaixam. Primeiro, Agregados: um grupo de objetos tratado como uma unidade para fins de mudança de dados, com uma única Entidade raiz controlando todo acesso externo. O exemplo mais nítido é um carro numa oficina mecânica — o carro tem identidade global (número de identificação do veículo), os pneus têm identidade só dentro do contexto daquele carro específico (ninguém consulta o sistema procurando um pneu avulso), e um bloco de motor com número de série pode virar a raiz do seu próprio Agregado separado. As regras são rígidas: nada fora do limite pode referenciar o que está dentro, exceto a raiz; só raízes de Agregado podem ser buscadas diretamente no banco; excluir a raiz exclui tudo dentro de uma vez. Segundo, Fábricas: a criação de um objeto complexo não é trabalho do próprio objeto, da mesma forma que montar um motor não é trabalho do motor rodando. Deixar o código cliente montar objetos de domínio complexos o acopla à estrutura interna deles — toda mudança na implementação vira uma mudança no cliente também. O exemplo da Conta de Corretagem mostra quando faz sentido dar à raiz de um Agregado o controle sobre a criação de outro objeto relacionado (uma Ordem de Negociação) mesmo quando ele não pertence ao mesmo Agregado. Terceiro, Repositórios: como você pega a primeira referência a um objeto no meio do seu ciclo de vida, sem deixar a lógica de consulta SQL vazar pra todo canto do código e virar o verdadeiro "modelo" por acidente? Um Repositório dá a ilusão de uma coleção em memória de todos os objetos de um tipo — e, crucialmente, só deveria existir para raízes de Agregado que realmente precisam de acesso global, nunca para objetos internos que deveriam ser alcançados só por travessia a partir da raiz. 📖 Baseado no Capítulo 6 ("O Ciclo de Vida de um Objeto de Domínio") de "Domain-Driven Design: Atacando as Complexidades no Coração do Software", de Eric Evans. #DomainDrivenDesign #DDD #EricEvans #EngenhariaDeSoftware #ArquiteturaDeSoftware