CODEWITHSUNDEEP
domain-driven-designaggregatebounded-contextsdomain-events
Oliver
Oliver

Reputation: 433

DDD - Multiple Bounded Contexts because of differing aggregate data?

We try to split up our domain into bounded contexts with the goal to have a modular application design/architecture.

We did an enlightening EventSorming session which helped us a lot to identify bounded contexts and its aggregates. After the workshop every participant agreed on the bounded contexts we identified.

Nevertheless we feel uncomfortable as we fear our bounded contexts are still too large. EventStomring focusses on the domain events / process and that's the major building block we used to identify our bounded contexts.

We also identified aggregates like "Contract". Every contract nearly follows the same process, but the amount of data these contracts contain can differ massively. There are very simple contract types and contract types which include a lot of additional data and attachments.

Is it meaningful to declare another bounded context just because the aggregate's data is more complex?

Both approaches have their drawbacks:

  1. Implementing all contract types in one bounded context might lead to a lot of if-Statements in the code in order to handle the differing data.
  2. Extracting a new bounded context might lead to a lot of duplicate code just because some data differs.

Any suggestions / best practices how to handle this?

Upvotes: 2

Views: 1540

Answers (3)

choquero70
choquero70

Reputation: 4754

...domain events / process and that's the major building block we used to identify our bounded contexts

BCs are not identified by processes, BCs are related to the language. Each BC has its own ubiquitous language (UL). A BC is the context in which a concept has meaning. Anyway BCs belong to the solution space. First of all you should explore the domain (problem space) and split it in subdomains, distilling the core domain. Then you model each subdomain. A BC is the context where a model lives. Ideally the relationship between subdomains and BCs is 1:1.

The process of discovering subdomains is iterative, and you will find them as you know the domain better, talking to experts. When you find a word that may have different meanings, or when two different words have the same meaning, then it means that you are crossing a boundary between BCs.

So, subdomains identification is not about processes, but about concepts and UL.

Is it meaningful to declare another bounded context just because the aggregate's data is more complex?

No, you shouldn't create BCs arbitrary just because aggregates are complex. BCs are based on the UL.

Any suggestions / best practices how to handle this?

You should learn more about the domain (contract, types, etc) by talking to domain experts, and study your aggregate (transactional consistency)... Anyway, if you split your aggregate into anothers, it doesn't mean that they belong to different BCs, they still can belong to the same BC. A BC can have more than one aggreagate. It all depends on your concrete domain.

Upvotes: 4

guillaume31
guillaume31

Reputation: 14080

  • No specific business teams for different kinds of contracts
  • No dedicated dev team for specific kinds of contracts
  • Same ubiquitous language is used for all contracts
  • Every contract nearly follows the same process

These to me are signs that all contracts belong to the same business subdomain and should ideally be in the same Bounded Context - unless legacy or third party systems force you otherwise.

Upvotes: 0

Robert Bräutigam
Robert Bräutigam

Reputation: 7744

Bounded contexts have little to do with if-statements, so I'm not sure what you mean.

Bounded contexts are a semantically closed set of business functionalities. Basically your bounded context is well defined if it can execute its functions in complete isolation, even if the other contexts are not available.

Other than that, you can have any design inside of the context. I feel the amount of if-statements depends more on your class/code-design, like whether you use polymorphism correctly, interfaces, things like that.

But, to your point: You don't need to have everything perfect the first time. If you identified some valid contexts, you already did the hard part. If any context can be further divided, that could happen later anytime with little impact on others (since contexts are more or less isolated).

Upvotes: 0

Related Questions