DDD: Handle domain events directly in aggregate?

Question

Our subdomain has two primary aggregate types: Locations and pallets. Each location keeps track of how many pallets it holds, and each pallet can only be placed on one location at a time. Assume that there are many instances of each type and their associations change often, so it is not feasible to put all of them into one common parent aggregate.

Consider this solution (only domain model shown):

public class Pallet : Aggregate
{
  public int LocationId { get; private set; }

  public void PlaceOnLocation(int locationId)
  {
    this.LocationId = locationId;

    this.emitDomainEvent(
      new PalletPlacedOnLocationDomainEvent(this.Id, locationId)
    );
  }
}

public class Location : Aggregate
{
  public int Load { get; private set; } = 0;

  public void OnPalletPlaced(PalletPlacedOnLocationDomainEvent event)
  {
    if (event.LocationId != this.Id) throw ArgumentException(); // Precondition

    this.Load++;
  }
}

Not shown here are the application layer handlers that handle transactions as well as load and save the aggregates.

Note that instead of OnPalletPlaced(...) I could have used an IncreaseLoad() method on the location. In this case, however, I would have introduced two issues:

• Leaked the relationship between the domain event and its effect from the domain layer to the application layer.

• Opened up the possibility for another (illegal) use case that increases the load without actually placing a pallet on that location.

Is it a valid approach to handle domain events directly in the aggregate like this?

Answer 1

An aggregate has the responsibility of maintaining the invariants required by the business logic (e.g. limits on how many pallets are in a given location or a prohibition on pallets containing certain items from being placed in a given location).

However, a domain event represents a fact about the world which the aggregate cannot deny (an aggregate could ignore events if they have no meaning to it (which is not a question of validation, but of the type of event: the aggregate's current state cannot enter into it)). If an aggregate handles domain events, it therefore should do so unconditionally: if the business rule the location aggregate enforces is that there cannot be more than 20 pallets in a location, then a domain event which effectively leads to there being 20 thousand pallets in a location means that you have 20 thousand pallets in that location. In short, this means that the only domain events which should be handled as domain events by an aggregate are those domain events which were validated against the aggregate before they were emitted. It's only really in event-sourcing or event-sourcing-adjacent approaches where you would see domain events being processed in the context of an aggregate.

This doesn't preclude recognizing that one component's event can be another component's command. The domain event could be treated as a command and be rejected or itself result in more domain events (e.g. "there are too many pallets in location XYZ!").

Answer 2

I don't know the domain, so I'll just mention some considerations. Many different choices may be valid depending on your use case and architectural design.

Assume that there are many instances of each type and their associations change often, so it is not feasible to put all of them into one common parent aggregate.

Having two separate aggregates in this subdomain may be warranted, but it also depends on how you sliced the subdomains in your Context Map. If you are in the transportation sector, your core domain may be 'Inventory Management' and your aggregate root is then the total Inventory, while Pallets and Locations are just domain entities. The inventory thus becomes the coordinator you can use.

There may be other subdomains involved in the Context Map where these entities also play a role, but in their own Bounded Contxt, e.g. Order Shipping (tracking the Pallets of an Order as they move to the Customer) and Warehouse Management (capacity planning of a single Location).

Is it a valid approach to handle domain events directly in the aggregate like this?

I would in general avoid it. In my own DDD architecture I use a Ports & Adaptors design and CQRS (and considering an actor model, where the actors reside in the Application layer). I don't use Event Sourcing or Microservices, but want to retain the option to easily add them later, if need arises (i.e. they are optional).

Now, why would I avoid this design? First of all you have created a tight coupling between two aggregates. What if my warehouse facilitates many different types of storage besides pallets? It may be okay if that's certainly not the case, and both aggregates really belong in the same subdomain. But what if you need to handle events from different subdomains?

In my design I set things up more or less like this:

• An Adapter endpoint (e.g. REST API) creates a Command or Saga and invokes the Application Layer
• Application layer handles Commands and Sagas. The handler contains the plumbing needed to invoke the Domain appropriately (validates command, loads aggregate from DB, etc.)
• Domain layer contains Aggregate (usually 1 per subdomain), Entities, Value Objects and Events.
• Aggregate, of course, is where stuff happens: the single point of entry. I just invoke methods and publish events here.
• Event handling is not part of the domain layer. I have a Publish/Subscribe mechanism in the Application layer, and it is used in the Adapters (e.g. to trigger a Saga and issue a follow-up Command).
• The aggregate methods either return nothing in most cases, or may return a value / raise an exception if this can be easily dealt with in the command handler and is not directly domain-related (in which case a domain event is more appropriate).

From @levi-ramsey answer:

If an aggregate handles domain events, it therefore should do so unconditionally: if the business rule the location aggregate enforces is that there cannot be more than 20 pallets in a location, then a domain event which effectively leads to there being 20 thousand pallets in a location means that you have 20 thousand pallets in that location.

Indeed. But this should be impossible as your domain shouldn't allow this to happen. Hauling back to your subdomain design and context map, it is interesting to consider whether it is complete.

In reality you don't drive to a warehouse, drop off your pallet and leave, and then let the workers at that location deal with the problem that the warehouse is at full capacity.

If you'd do Event Storming you may find that a Saga is involved to coordinate the whole process. You'd most likely e.g. "receive (or request) a freight letter from HQ telling you which Location to visit, that has storage space already reserved." (Note: there's probably Ubiquitous Language in this sentence).

A whole bunch of concepts may flow from this:

• FreightDelivery saga
• Inventory.ReserveStorageSpace command
• StorageSpaceReserved event, with a LocationID set
• StorageUnit.PALLET enum
• ... etcetera

Looking at this now, with the insights I gleaned from quickly typing this answer, I now wonder the following: Should Pallet be an aggregate root? Should Pallet have a PlaceOnLocation method? A pallet doesn't place itself when you command it to. It is not an actor. Maybe Pallet should just be a regular domain entity that has a Location property which is updated as it is moved around.

---

I hope you found this useful. Once again I want to stress that there's no one good solution, there are many variations that make perfect sense :)