1

I'm not sure the best way of phrasing the question, but let me explain!

Say I have a bounded context of Customer. I then want to create another bounded context around subscriptions. Normally I would use subscription as the aggregate root and have a property of customerId.

However, I have some business logic that says a customer can have many subscriptions, but only one active at a time. To implement this easily I could have Customer as the root which has a collection of subscriptions and then the logic would be fairly easy to implement within the customer root.

I believe this is OK as it's extending the Customer object with another property and serves purpose. If there wasn't the business logic of only a single active subscription then this wouldn't serve a benefit and I could just use Subscription as the root.

Does this sound OK to use the customer as the root again?

Thanks

Improve this question
2
  • Just to get the terminology straight: from what you describe, these seem to be just two aggregates, rather then bounded context, right? In general, you should design your objects and aggregates in a way that supports the business logic and other constraints, and works well with the technologies you use, so reexamine if the current structure and the way you've separated things helps or gets in the way. Also, are these elements yet to be designed and implemented, or do these structures already exist and you are facing a new requirement?
    – Filip Milovanović
    Commented Jul 8, 2019 at 16:59
  • @FilipMilovanović these are the aggregates that I'm looking at at the moment, but the system is much larger than this. I'm currently at the design stage, so nothing existing yet (well, apart from a monolithic app).
    – ADringer
    Commented Jul 9, 2019 at 7:17

1 Answer 1

Reset to default
1

One of the primary rules to keep in mind while designing aggregates is that Aggregates are intended to define consistency and transactional boundaries. Within their boundary, all invariants of the aggregate are satisfied ALL the time.

To elaborate on the terms, an invariant is simply a business rule that must always be consistent. The consistency here refers to transactional consistency (immediate and atomic, with ACID properties), and not eventual consistency.

Applying this principle to your problem, one of the invariants of your Customer aggregate is that there is only one active subscription at any point in time. To truly satisfy this invariant, the Customer Aggregate has to own the subscription and all changes to subscriptions should pass through the customer aggregate.

So yes, you should definitely use the Customer entity as the root/Aggregate. 👍

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.