How to create new aggregate root in CQRS

cqrsdomain-driven-designentityevent-programmingevent-sourcing

How should we create new aggregate roots in cqrs architecture? In this example I want to create new aggregate root AR2 that holds reference to first one AR1.

I'm creating AR2 using AR1 method as starting point. So far I see few options:

Inside method in AR1 createAr2RootOpt1 I could call new AR2() and save this object to db imediatelly using domain service that has acces to repository.

I could emit event in first aggregate root eg. SholdCreateAR2Event and then have stateless saga that reacts on this and issues command CreateAR2Command which is then handled and actually creates AR2 and emits AR2CreatedEvent. In case of using event sourcing SholdCreateAR2Event would not be preserved in event store, since it does not affect the state of first aggregate root. (Or should we still save this in event store?)

class AR1{
    Integer id;
    DomainService ds;

    //OPTION 1
    void createAr2RootOpt1(){
        AR2 ar2 = new AR2();
        ds.saveToRepo(ar2);
    }

    //OPTION 2
    void createAr2RootOpt2(){
        publishEvent(new SholdCreateAR2Event());    //we don't need this event. Shoud it still be preserved in event store?
    }
}

class AR2{
    Integer id;
    Integer ar1Id;

    void handle(CreateAR2Command command){
        //init this AR with values and save
        publishEvent(AR2CreatedEvent());    //used for projections afterwards and saved inside AR2 event store
    }
}

class Saga{
    void handle(SholdCreateAR2Event ev){
        emitCommand(new CreateAR2Command());
    }
}

Which is more proper way to do this?

Best Answer

I think that option no. 2 is the solution, with a small but important modification: AR1 should not emit a event who's purpose is to create the AR2, instead it should emit a AR1WasCreated event. This event should be persisted in the event store, as it is an important event marking the birth of AR1. Then, a Saga whould listent for AR1WasCreated event and generate a command to create AR2: CreateAR2Command.

Option no.1 is very wrong. You should never inject that kind of domain service in an Aggregate. Aggregates should be pure, with no side effects other that the generation of events.

P.S. I never emit events from the constructor of the Aggregate as there is a distinction between creating an instance of an object (in the programming language sense) and the creation (the birth if you want) of an Aggregate. I emit events only from a handle method (when handling a command).

Related Solutions

Sharing of event source stream between aggregates

This events will be fetched by AR2 and then processed.

Ohh, that sounds like a bad idea.

One more notice - in AR2 this layer would be read-only = needed to do some business logic inside AR2.

So looking at your picture, AR2 is writing out events (d,e,f), which says that AR2 is not read only -- which is good; read only aggregate roots don't make sense.

The usual pattern for what you seem to be trying to do here is to use a process manager to coordinate the activities of the two aggregate roots. The role of the process manager is to listen for events, and respond by dispatching commands.

In that picture, you would have something like the following:

Command(A) arrives at AR(1)
    AR(1) loads its history [x,y,z]
    AR(1) executes Command(A), producing events [a,b,c]
    AR(1) writes its new history [x,y,z,a,b,c]

Events(a,b,c) are published

ProcessManager receives the events (a,b,c)
    ProcessManager dispatches Command(B) to AR(2)

Command(B) arrives at AR(2)
    AR(2) loads its own history [d,e,f]
    AR(2) executes Command(B), producing events [g,h]
    AR(2) writes its new history [d,e,f,g,h]

Events(g,h) are published

Trying to have two different aggregate roots share a common event history is really weird; it strongly suggests that your model needs rethinking (why are there two different authorities for the same fact? what happens when AR1 writes an event that violates the invariant enforced by AR2?).

But taking some of the state from one event, and making that an argument in a command sent to another aggregate; that pattern is pretty common. The process manager itself is just a substitute for a human being reading the events and deciding what commands to fire.

I always need current state of AR1 layer, even if AR2 is created from the scratch it needs to have content of layer from AR1. The layer would be read only.

There's no such thing as getting the "current" state of another aggregate; AR1 could be changing while AR2 is doing its work, and there's no way to know that. If that's not acceptable, then your aggregate boundaries are in the wrong place.

If stale data is acceptable, you can have the AR2 command handler query the state of AR1, and use that information in processing the command. If you are going to do that, I normally prefer to wrap the query in a Domain Service, which gives you an extra layer of indirection to work with (the domain model doesn't need to know how the service is implemented). In this design, AR2 doesn't see the AR1 events at all; AR2 passes some state to the domain service, and the domain service looks at the events to figure out the answer, and passes that answer back as a value that AR2 will understand.

Whittaker's solution isn't bad; once you recognize that the data is stale anyway, you have the option of deciding whether the state available at the time of creating the command is good enough. I'm of mixed minds on this -- putting everything into the command is nice, and really easy to understand. On the other hand, there is a larger window for a change to happen, and to some degree discovering the right data to use requires accessing state internal to the aggregate that can change while the command is in flight.

I much prefer designs where the aggregates aren't coupled, though.

But it seems that this is again sharing of data between the AR-s, since fat command will use data from layer from AR1 to supply to AR2

You might look into what Udi Dahan has to say about services as technical authorities. In that case, the data that gets shared is mostly limited to opaque identifiers.

Domain-Driven Design – Handling Aggregate Root with Deep Object Hierarchy

If you want to do it the right way as DDD suggests, then you are only allowed to change shape colour by using a method on the aggregate root directly and you cannot do it on the shape directly. The aggregate root is only allowed to expose its internal entities as read-only objects (e.g. exposing internal collections as IEnumerable).

However, good aggregate design is also a simple design and when you come to a situation in which your aggregate root grows, the first question you should ask yourself is: Which context does the aggregate actually provide for the entities?

In your case, you should think whether the Shape really is just an internal entity, or whether the Shape could be an aggregate root on its own?

Your Shape class should remain an only internal entity of the Picture aggregate root when the Picture defines some rules among multiple Shape instances, such as: A picture may not contain two shapes of the same color. Having defined this rule, the aggregate root - knowing about all of its shapes - can now verify this rule.

But, if the Picture aggregate root does not really define any rule as such and only internally stores the Shapes then the Shape really should be an aggregate root on its own with the following structure:

class Shape
{
    private ShapeId shapeId;
    private PictureId associatedPictureId;
    private ShapeType type;
    private Color color;
}

and the Picture would have the following method:

class Picture
{
    private PictureId pictureId;

    public Shape AddShape(ShapeId shapeId, ShapeType shapeType, Color color)
    {
        return new Shape(shapeId, pictureId, shapeType, color);
    }
}

Always think of an aggregate root as a protector of boundaries which the aggregate root defines for its internal parts. If it does not define any boundaries and rules for its internal parts, split the internals into separate aggregate roots to remove complexity.

Best Answer

Related Solutions

Sharing of event source stream between aggregates

Domain-Driven Design – Handling Aggregate Root with Deep Object Hierarchy

Related Topic