CQRS Command – Handling CQRS Commands with Multiple Aggregate Roots

cqrsdesign-patternsdomain-driven-design

I have have a business process that receives an order request which also includes full customer information.

In the cases where the external customer ID from that order request is not found in our DB, we need to process that piece of the "create order" command, before we can actually save the order for that customer.

In the cases where we do find a matching customer ID but the address record in the DB differs from the one in the order request, we need to insert it as a new address record for that customer id (many CustomerAddress to 1 Customer) – note that this address also gets saved as part of the order's shipping address value object, because… well… those change, but the order is point in time.

I originally designed an orders aggregate with my Order entity as the aggregate root (note that I have the Id property defined in a base Entity class, which the AggregateRoot abstract class also extends, but omitted here for brevity):

public class Order : AggregateRoot 
{
   //ctor ....

   public long CustomerId { get; }
   public Address ShippingAddress { get; } //value type

   private readonly List<OrderItems> _items = new List<OrderItems>();
   public IReadOnlyCollection<OrderItems> Items => _items.AsReadOnly();

   // more props and behavior methods here....
}

In a separate aggregate, named "customers', I have my Customer aggregate root and a CustomerAddress entity:

public class Customer : AggregateRoot
{
   public string ExternalId { get; }

   private readonly List<CustomerAddress> _addresses = new List<CustomerAddress>();
   public IReadOnlyCollection<CustomerAddress> Addresses => _addresses.AsReadOnly();
   // more props and behavior methods...
   public void AddNewAddress(string externalKey, Address addressInfo)
   {
       _addresses.Add(new CustomerAddress(externalKey, addressInfo, this));
   }
}
public class CustomerAddress : Entity
{
   //ctor ...

   public string ExternalAddressKey { get; }
   public Customer Customer { get; }
   public Address AddressInfo { get; }

   // more props and behavior methods...
}

There will be times when we'll manage (add new, and update) customer data all by itself via UI and not in the context of an order. However, about 50-60% of the time the customer info will actually arrive as part of the order request API and sent to the internal command handler and we need to check if it already exists as mentioned above.

I suspect that I may have my aggregate boundaries designed incorrectly, but I am not sure, as I keep going back and forth in my mind how to achieve the business requirement as stated above using proper CQRS + DDD patterns.

I am not sure if I should treat my command handler as a sort of process manager/app service, and if I do that I'd be creating multiple transactions (working w/ 2 different aggregates) in the same command, which seems to go against the tenets of DDD.

Would appreciate some guidance on this. Thanks!

Best Answer

A comment from Eric Evans DDD Book:

On the other hand, a feature that can transfer funds from one account to another is a domain SERVICE because it embeds significant business rules (crediting and debiting the appropriate accounts, for example) and because a “funds transfer” is a meaningful banking term. In this case, the SERVICE does not do much on its own; it would ask the two Account objects to do most of the work. But to put the “transfer” operation on the Account object would be awkward, because the operation involves two accounts and some global rules.

Evans, Eric.

Domain-Driven Design: Tackling Complexity in the Heart of Software (S.107).

Pearson Education. Kindle-Version

Sometimes it is just not possible to achieve immediate consistency with a single aggregate root and it is not desirable to implement a long-running process. Then it is perfectly fine to use a domain service to coordinate changes on several aggregate roots.

Related Solutions

CQRS – Querying Aggregate Root Using Fields Other Than GUID

CQRS/ES is a tricky architecture in many aspects and you've found one of them.

First of all, since you're storing events it is very hard to query an entity based on its data since you don't actually have the entity-state stored anywhere, only the events that will generate such state. It won't work like a regular state-based storage where you can go into your record and query a person from its name, for an example.

So, for the command-side (the ES side) of your equation, you should only be able to reliably fetch a whole entity by its ID and then replay the events to rebuild its final state.

Now, of course, there are business scenarios where you will need to find a person from its name. When that happens, the easiest way to proceed is to simply query the read model and then proceed to fetch the ID to go get the command entity from it. Please be aware that the read-side is subject to a propagation delay from the command-side. That means it's only eventually consistent. Once a command is triggered and processed on the command-side, there will be a random period of time where the read-side will not reflect this latest change, so your code must be prepared for that.

However, you should really try to make your application layer communicate in terms of your entity IDs to avoid this extra step as much as possible and it shouldn't be that hard.

Imagine some client is reading data pertaining to one of your entities. If that is happening, that client probably already holds the ID information of that given entity. So if he wants to send a command to such entity, he should be able to fire it based on its ID and not on other state-based data.

Should CQRS Command Perform a Query?

Let's start with a short review of the problem-space here. The fundamental benefit of adopting a CQRS pattern is to solve/simplify your problem domain by reducing the interleaving and leakage that begins to occur when utilizing the same model for your write-side as your read-side. Often, the tension that arises serves as a detriment to both. CQRS seeks to relieve this tension by separating (decoupling logically and possibly physically) the write-side and read-side of your system. With the above in mind it should be clear that neither your commands nor queries should be coupled to a logical entity from the other "side".

Given the above, we can now formulate a direct answer to your question: Yes, you can query your data store within a command handler provided the query is issued against your command model. Because your OrderCreateCommandHandler is part of the command model of your application, we want to avoid coupling it to any part of your read model. It's unclear whether or not this is case given the example code (although the name CustomerQuery does raise some suspicions).

More important than the answer above though is that... there is something else that feels fishy about the example you have provided. Can you feel that too?

What I see here is quite a bit of coupling. Your handler is retrieving a CustomerResult (VO?), then breaking down all of it's data into another entity's constructor (Customer), then passing the Customer to a factory method of yet another entity. We have quite a bit of "asking" happening here. That is, we are passing around a lot of data in way that creates coupling.

Furthermore, the command handler doesn't "read" in a very declarative fashion (which is what we want to strive for). What I mean is that it's kind of hard to "see" what's happening in your method because there is so much plumbing getting in the way. I think we can come up with a more cohesive/declarative solution.

Given that the general "flow" of a command handler can be broken down into three simple steps:

Retrieve all data (domain model) necessary to carryout the use-case
Coordinate the data to fulfill the use-case
Persist the data

Let us see if we can come up with a simpler solution:

buyer = buyers.Find( cmd.CustomerId );

buyer.PlaceOrder( cmd.Products );

buyers.Save( buyer );

Ah ha! Much cleaner (3 simple steps). More importantly though, not only does the code above achieve your same goal, it does so without creating many dependencies between disparate objects as wells as functioning in a more declarative and encapsulated manner (we aren't "newing" anything or calling any factory methods)! Let's break this down piece by piece so we can understand "why" the above may be a better solution.

buyer = buyers.Find( cmd.CustomerId );

The first thing I've done is introduce a new concept: Buyer. In so doing this, I am partitioning your data vertically according to behavior. Let's let your Customer entity have responsibility for maintaining Customer information (FirstName, LastName, Email, etc.), and allow a Buyer to be responsible for making purchases. Because some Customer information needs to be recorded when a purchase is made, we will hydrate a Buyer with a "snapshot" of that data (and possibly other data).

buyer.PlaceOrder( cmd.Products );

Next we coordinate the purchase. The above method is where a new Order is created. An Order doesn't just appear out of nowhere right? Something must place it, so we model accordingly. What does this achieve? Well, the Buyer.PlaceOrder method provides a place in your domain to throw BuyerNotInGoodStanding, OrderExceedsBuyerSpendingLimit, or RepeatOrderDetected exceptions. By only creating an Order in the context of it's placement, we can enforce how an Order can come about. In your example, either your application-layer command handler or your Order factory method would have to be made responsible for enforcing each invariant. Neither is a good place for checking business rules. Additionally we now have a place to raise our OrderPlaced event (which will be necessary to keep your payment context decoupled), and also we can simplify your Order entity as it now only needs a scalar buyerId to keep reference to it's owner.

buyers.Save( buyer );

Pretty self-explanatory. A Buyer now contains all of the information you need to persist both an Order and a "snapshot" of Customer data. How you organize that data internally and take it apart for persistence is up to you (hint: A Buyer needn't be persisted at all, for example. Just the Order it contains).

EDIT

The example solution (if we can call it that) that I posted is one meant to get the "gears turning", and doesn't necessarily represent the best-possible solution to the problem at hand. That is, your problem. It is totally possible (even likely) that introducing the concept of a Buyer aggregate is over-engineering given that there had been no mention of any sort of rules regarding how an Order can be placed. For example:

customer = customers.Find( cmd.CustomerId );

order = customer.PlaceOrder( cmd.Products ); // raise OrderPlaced

orders.Save( order );

may be a totally valid approach! Just be sure to include all of the necessary information in the CustomerInformationSlip (your "snapshot") attached to the Order to allow it to enforce any invariant controlling how it can be modified. For example:

order.ChangeShippingAddress( cmd.Address ); // raise ShippingAddressChanged

The above may throw an OrderExceedsCustomerShippingDistance if each Customer has their own rules regarding how far you will ship to them given their account tier.

Let the rules dictate the design!

Best Answer

Related Solutions

CQRS – Querying Aggregate Root Using Fields Other Than GUID

Should CQRS Command Perform a Query?

Related Topic