2

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?

APC
  • 144,005
  • 19
  • 170
  • 281
Oliver
  • 353
  • 1
  • 4
  • 16
  • Are the different types of contracts handled by different operational teams? If so, do they use different vocabulary to describe their work? – guillaume31 Dec 11 '18 at 14:02
  • Not necessarily. The problem is that our software just acts as a "proxy" for those contracts. The contracts are structured by third parties. Currently we try to map all those different contracts to one structure (model) to rule them all which seems not to be a good idea. ;-) Therefore we want to split things, but we are not sure how far this split should go. – Oliver Dec 11 '18 at 15:07

3 Answers3

4

...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.

choquero70
  • 4,470
  • 2
  • 28
  • 48
0

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).

Robert Bräutigam
  • 7,514
  • 1
  • 20
  • 38
  • Thanks for your answer. So you think it's better to put too much stuff in a bounded context in the first place than to seperate things which might belong together? – Oliver Dec 11 '18 at 09:10
  • Kind-of. What I'm saying is: iterate! If you are unsure about it and there is no immediate need (no architectural constraints or requirements), then don't do it now, delay this decision. If you feel it's too much stuff for one context, as in too much functionality for one team to handle, then you have a need to split now. Wait until a good, *immediate* reason is visible. Until then, have a good internal design that gets rid of your if-statements. – Robert Bräutigam Dec 11 '18 at 09:35
0
  • 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.

guillaume31
  • 13,738
  • 1
  • 32
  • 51