Bounded contexts sharing a same aggregate

Question

DDD exposes bounded contexts, domain models, aggregates... but I often miss the keypoint of business rules. I would like to know how business rules integrate into this approach. Here is an example :

Imagine you have 2 bounded contexts in a credit company. One for debt recovery, the other for early refunds. These contexts embed real business specificities. In a conceptual point of view, I think these bounded contexts should separately embed common model parts, and similar domain model entities (graph of 3 or 4 accountancy entities). Even if their respective models embed a common submodel (we do not plan it can change), business rules that apply to these submodels are different. A DebtRecoveryService ensures rules are correctly applied, and another EarlyFundsService does the same, with specific accountancy rules.

• Should this submodel be embedded and "served to others" by another dedicated bounded context if different business rules apply to them (in terms of maths and respective behaviours ?).
• What defines an aggregate, is it only a part of a model ?
• Do specific business rules define specific aggregates ?

Do you think an aggregate should be considered only for the entity graph it represents, and be "reused" by other bounded contexts. Is it a good case for CQRS ?

Thanks,

Answer 1

It seems pretty clear that according to DDD you should duplicate you models when they are shared by different bounded domains.

Also service patterns encourage not using the same object on both sides of the service.

However. If you are using POCO style data objects and encapsulating business logic in services rather than the classic OO object graph approach, you are essentialy employing multiple patterns to protect yourself from the same issue.

In this case the benefits of code reuse from having a shared common model could out-weigh the potential tech debt should the domain meaning of that model drift apart between bounded contexts over time.

Essentialy though this could happen with in a bounded context. I feel your question could boil down to "Have I chosen the correct bounded contexts?" which of course is subjective.

Answer 2

One basic rule is that Domain Services should only be used when some domain logic doesn't seem to fit in any Entity. Domain Services are not meant as Bounded Context-specific "watch dogs" to control changes made to shared dumb data structures.

If domain invariants can be contained in an Aggregate, definitely put them there -- it's normal to have two Aggregates with similar data but different rules in two BC's, that's why you have Bounded Contexts in the first place.

As a side note, Bounded Context design is not something you should improvise. I strongly recommend reading the tactical and strategic patterns described in the original blue book as well as Vaughn Vernon's red book.

Patterns such as Context Mapping or Shared Kernel, to only name a few, are helpful tools to know when designing your Bounded Contexts. BC design doesn't only depend on business concerns but also organizational factors, such as which teams will maintain the contexts, historical factors (legacy context vs greenfield one), etc.

You'll learn about all that and a ton of other essential stuff in the books, which will hopefully dissipate the confusion you seem to be in.