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