Relación entre los manejadores de comandos, agregados, el repositorio y el almacén de eventos en CQRS

Una pequeña variación de Dennis excelente respuesta:

• Cuando se trata de casos de uso "creacionales" (es decir, que deberían derivar nuevos agregados), trate de encontrar otro agregado o fábrica a la que pueda mover esa responsabilidad. Esto no entra en conflicto con tener un ctor que toma eventos para hidratar (o cualquier otro mecanismo para rehidratar para el caso). A veces la fábrica es solo un método estático (bueno para la captura de "contexto" / "intención"), a veces es un método de instancia de otro aggregate (buen lugar para la herencia de" datos"), a veces es un objeto de fábrica explícito (buen lugar para la lógica de creación" compleja").
• Me gusta proporcionar un método GetChanges() explícito en mi agregado que devuelve la lista interna como una matriz. Si mi aggregate debe permanecer en la memoria más allá de una ejecución, también agrego un método AcceptChanges() para indicar que la lista interna debe borrarse (normalmente se llama después de que las cosas se descargan al almacén de eventos). Usted puede utilizar ya sea un tirón (GetChanges/Changes) o push (think. net event o IObservable) modelo basado aquí. Mucho depende de la semántica transaccional, tecnología, necesidades, etc ...
• Tu eventstream es una lista vinculada. Cada revisión (evento/conjunto de cambios) apunta a la anterior (también conocida como el padre). Tu eventstream es una secuencia de eventos / cambios que ocurrieron en un agregado específico. La orden solo debe garantizarse dentro del límite agregado.

Yo casi estoy de acuerdo con yves-reynhout y dennis-traub pero quiero mostrarles cómo hago esto. Quiero despojar a mis agregados de la responsabilidad de aplicar los eventos en sí mismos o rehidratarse; de lo contrario, hay mucha duplicación de código: cada constructor de agregados se verá igual:

UserAggregate:
    ctor(eventStream)
         foreach (event in eventStream)
            this.Apply(event)


OrderAggregate:
    ctor(eventStream)
         foreach (event in eventStream)
            this.Apply(event)


ProfileAggregate:
    ctor(eventStream)
         foreach (event in eventStream)
            this.Apply(event)

Esas responsabilidades podrían dejarse al despachador de órdenes. El comando es manejado directamente por el agregado.

Command dispatcher class

    dispatchCommand(command) method:
        newEvents = ConcurentProofFunctionCaller.executeFunctionUntilSucceeds(tryToDispatchCommand)
        EventDispatcher.dispatchEvents(newEvents)

    tryToDispatchCommand(command) method:
        aggregateClass = CommandSubscriber.getAggregateClassForCommand(command)
        aggregate = AggregateRepository.loadAggregate(aggregateClass, command.getAggregateId())
        newEvents = CommandApplier.applyCommandOnAggregate(aggregate, command)
        AggregateRepository.saveAggregate(command.getAggregateId(), aggregate, newEvents)

ConcurentProofFunctionCaller class

    executeFunctionUntilSucceeds(pureFunction) method:
        do this n times
            try
                call result=pureFunction()
                return result
            catch(ConcurentWriteException)
                continue
        throw TooManyRetries    

AggregateRepository class

     loadAggregate(aggregateClass, aggregateId) method:
         aggregate = new aggregateClass
         priorEvents = EventStore.loadEvents()
         this.applyEventsOnAggregate(aggregate, priorEvents)

     saveAggregate(aggregateId, aggregate, newEvents)
        this.applyEventsOnAggregate(aggregate, newEvents)
        EventStore.saveEventsForAggregate(aggregateId, newEvents, priorEvents.version)

SomeAggregate class
    handleCommand1(command1) method:
        return new SomeEvent or throw someException BUT don't change state!
    applySomeEvent(SomeEvent) method:
        changeStateSomehow() and not throw any exception and don't return anything!

Tenga en cuenta que esto es pseudo código proyectado desde una aplicación PHP; el código real debe tener cosas inyectadas y otras responsabilidades refactorizadas en otras clases. La idea es mantener los agregados lo más limpios posible y evitar la duplicación de código.

Algunos aspectos importantes sobre los agregados:

1. los manejadores de comandos no deben cambiar de estado; producen eventos o excepciones de lanzamiento
2. el evento que se aplica no debe lanzar ninguna excepción y no debe devolver nada; solo cambian estado interno

Una implementación PHP de código abierto de esto se puede encontrar aquí.