DDD Modify one aggregate per transaction with invariants in both aggregates

Question

Suppose I have an aggregate root Tenant and an aggregate root Organization. Multiples Organizations can be linked to a single Tenant. Tenant only has the Id of the Organizations in it's aggregate.

Suppose I have the following invariant in the Organization aggregate: Organization can only have one subscription for a specific product type.

Suppose I have the following invariant in the Tenant aggregate: only one subscription for a product type must exists across all Organizations related to a Tenant.

How can we enforce those invariants using the one aggregate per transaction rule? When adding a subscription to an Organization, we can easily validate the first invariant, and fire a domain event to update (eventual consistency) the Tenant, but what happens if the invariant is violated in the Tenant aggregate?

Does it imply to fire another domain event to rollback what happens in the Organization aggregate? Seems tricky in the case a response had been sent to a UI after the first aggregate had been modified successfully.

Or is the real approach here is to use a domain service to validate the invariants of both aggregates before initiating the update? If so, do we place the invariants/rules inside the domain service directly or do we place kind of boolean validation methods on aggregates to keep the logic there?

UPDATE What if the UI must prevent the user from saving in the UI if one invariants is violated? In this case we are not even trying to update an aggregate.

Answer 1

One thing you might want to consider is the possibility of a missing concept in your domain. You might want to explore the possibility of your scenario having something as a Subscription Plan concept, which by itself is an aggregate and enforces all of these rules you're currently trying to put inside the Tenant/Organization aggregates.

When facing such scenarios I tend to think to myself "what would an organization do if there was no system at all facilitating this operation". In your case, if there were multiple people from the same tenant, each responsible for an organization... how would they synchronize their subscriptions to comply with the invariants?

In such an exercise, you will probably reach some of the scenarios already explored:

• Have a gathering event (such as a conference call) to make sure no redundant subscriptions are being made: that's the Domain Service path.

• Each make their own subscriptions and they notify each other, eventually charging back redundant ones: that's the Event + Rollback path.

• They might compromise and keep a shared ledger where they can check how subscriptions are going corporation wide and the ledger is the authority in such decisions: that's the missing aggregate path.

You will probably reach other options if you stress the issue enough.