Eventos de dominio con Spring Boot y MongoDB

Estoy trabajando DDDy Springusando MongoDB.

Ahora, ya que MongoDBes un DocumentDBy no hay validaciones de esquema presentes, AggregateRooty la clase Document que se almacena en MongoDB son dos clases diferentes y Repositorytraduce el contenido entre esas dos clases mientras lee y escribe datos en database.

Dado que la clase de entidad raíz es diferente de la clase que se almacena en la base de datos, Spring no activa la DomainEventsde AggregateRoot.

• ¿Hay alguna manera de que pueda activar los eventos de la entidad raíz desde el repositorio después de almacenar los datos en la base de datos? (tal vez mediante una invocación explícita)

• Dado que MongoDB y Aggregates son un ajuste 1: 1. Entonces, ¿eso significa que generalmente no deberíamos hacer dos clases diferentes, una como AggregateRooty otra Clase de documento para almacenar raíces agregadas en mongoDB? ¿No tendríamos que agregar la anotación @Document en la parte superior de nuestro agregado que filtraría el código de infraestructura en nuestro modelo de dominio?

Después de un tiempo descubrí la solución, de los votos positivos creo que otros están enfrentando el mismo problema, aquí está la solución:

Pregunta: ¿Podemos activar una invocación explícita para los eventos de dominio?

Respuesta: Sí, podemos. En SpringBootpodemos usar / Autowirela ApplicationEventPublisherinterfaz y luego llamar al publishEvent(event)método.

Si está creando una clase separada para la colección Db y Aggregate, necesitará exponer su DomainEventsmétodo y un método para ClearingDomainEventssu agregado, ya que AbstractAggregateRoot<T>tiene estos métodos como protected. A continuación se muestra un ejemplo de cómo generar un evento en la creación:

public class MyAggregateRootClass extends AbstractAggregateRoot<MyAggregateRootClass> 
{
    public MyAggregateRootClass(String property1, String property2) {

        // set the fields here
        registerEvent(new MyAggregateRootCreated(someArgs));
    }

    public Collection<Object> getDomainEvents() {
        return super.domainEvents();
    }

    public void clearDomainEvents() {
        super.clearDomainEvents();
    }
}

El código del repositorio se vería así:

@Repository
@RequiredArgsConstructor // using lombok here, you can create a constructor if you want
public class MyAggregateRepository {

    private final ApplicationEventPublisher eventPublisher;

    private final AggregateMongoRepository repository;

    public void save(MyAggregateRootClass aggToSave) {

        AggregateDao convertedAgg = new AggregateDao(aggToSave);

        repository.save(convertedAgg);

        // raise all the domain events
        for (Object event : aggToSave.getDomainEvents())
            eventPublisher.publishEvent(event);

        // clear them since all events have been raised
        aggToSave.clearDomainEvents();
    }
}

Entonces, ¿eso significa que generalmente no deberíamos hacer dos clases diferentes, una como AggregateRooty otra como Clase de documento para almacenar raíces agregadas mongoDB?

Respuesta : No, eso no significa eso. El objetivo de la DDDsería separarse infrastructurede Domainy mantener el carácter Domainagnóstico de todo el código de infraestructura. Si ambos son iguales, a continuación se muestra el impacto:

• Tener la @Documentanotación en su Aggregate Classlo haría cambiar su Domainsi está cambiando marcos o intercambiando Mongodbcon SQL.
• En el futuro, en caso de que su esquema de base de datos necesite cambiar, tendrá que cambiar también su clase agregada o tendrá que configurar las clases de adaptador.
• Dado que el dominio solo debería cambiar si hay un cambio en los requisitos comerciales y no debido a eso infrastructure dependencies, infrastructure annotationsingresar al sitio AggregateRootno sería la mejor manera

Si desea mantenerlo simple y usar la misma clase para ambos y no crear una clase separada, asegúrese de estar seguro de lo siguiente:

• Si está absolutamente seguro de que nunca cambiará las bases de datos ni los marcos.
• Tiene un simple modelo de dominio y que no es necesario para almacenar Entitiesel Aggregateen una recogida selectiva y que no hay ninguna posibilidad de que los Entitiesvolvería a crecer en su propioAggregates

Al final depende. Siéntase libre de dejar comentarios y haré todo lo posible para responderlos a todos, bastante activo en la pila.