Joana é a líder da equipe técnica que está modelando um novo...
Ao aplicar o DDD, Joana está ciente de que:
Gabarito comentado
Confira o gabarito comentado por um dos nossos professores
Gabarito: A
Fundamento decisivo: O elemento decisivo era identificar a natureza do evento de domínio na DDD: fato já ocorrido no domínio, o que afasta as demais alternativas.
- Se a assertiva tratar de evento de domínio como fato já ocorrido, verifique se a consequência apontada é a imutabilidade ordinária.
- Em agregados, confirme se o acesso externo está concentrado na raiz, e não espalhado por entidades internas.
- Em repositórios, procure a ideia de recuperar ou reconstituir objetos de domínio, não de entregar classes para instanciação.
- Quando aparecer Linguagem Onipresente, associe-a a vocabulário compartilhado do domínio, não a mecanismos estruturais como fábricas ou objetos de valor.
Clique para visualizar este gabarito
Visualize o gabarito desta questão clicando no botão abaixo
Comentários
Veja os comentários dos nossos alunos
Gabarito (A)
Características dos Eventos de Domínio
Algumas características importantes dos eventos de domínio:
1. Imutáveis: Um evento de domínio representa algo que já aconteceu e, por definição, o passado não pode ser alterado. Portanto, os eventos são imutáveis.
2. Nome descritivo: O nome de um evento de domínio deve ser claro e refletir algo que ocorreu no domínio, como PedidoCriado ou ClienteCadastrado.
3. Propagação de mudanças: Eventos de domínio são usados para notificar outras partes do sistema sobre mudanças de estado. Isso pode incluir sistemas externos ou processos que precisam ser disparados após um evento.
4. Baixo acoplamento: Diferentes serviços ou módulos podem se inscrever para ouvir eventos de domínio e responder a eles sem a necessidade de modificar o código que gera o evento.
Fonte: https://www.linkedin.com/pulse/entendendo-eventos-de-dom%C3%ADnio-ddd-rodrigo-de-oliveira-7hpsf/
Gabarito: A
Alternativa A: "eventos de domínio são ordinariamente imutáveis, já que são um registro de algo no passado". Isso é verdadeiro em DDD. Eventos de domínio representam algo que aconteceu, então são imutáveis. É um conceito comum.
Alternativa B: "mudanças no código representam adequações tecnológicas e não devem suscitar alterações no modelo". Isso é falso. Em DDD, o modelo e o código andam juntos; mudanças no código frequentemente refletem mudanças no modelo. O modelo não é estático.
Alternativa C: "agregados devem prover referências para cada entidade em seu contexto como guias para os objetos externos". Isso não é uma prática recomendada. Agregados devem ter uma raiz que é a única referência para objetos externos; não se deve expor entidades internas diretamente. Prover referências para cada entidade viola encapsulamento.
Alternativa D: "repositórios devem retornar classes ou coleções de classes a serem instanciadas por métodos externos de clientes". Repositórios retornam agregados ou coleções de agregados, mas a instanciação geralmente é interna. A afirmação diz "a serem instanciadas por métodos externos de clientes" - isso parece errado. Repositórios são responsáveis por recuperar e persistir agregados; os clientes não instanciam as classes retornadas, elas já estão prontas.
Alternativa E: "o uso da Linguagem Onipresente (Ubiquitous Language) expressa o modelo como fábricas encapsuladas por objetos de valor". Isso não faz sentido. A Linguagem Onipresente é uma linguagem comum entre especialistas de domínio e desenvolvedores, não tem relação com fábricas ou objetos de valor dessa forma.
Portanto, a correta é a alternativa A.
Fonte: DeepSeek
Clique para visualizar este comentário
Visualize os comentários desta questão clicando no botão abaixo
Conheça nossos planos