Breaking application to bounded contexts

4
votes

How do you plan and divide your application into bounded contexts? On the one hand it's very handy having all this decoupling, but on the other hand too much granularity can lead to a very cumbersome development. Where is this thin line? What factors do you take under consideration when designing your bounded contexts and context maps? Are they technical, strategic maybe?

In a lot of examples you see e-commerce app as a set of bounded contexts: catalog, shopping, invoicing, delivery etc.

Where are those coming from?

3
domain-driven-design

3 Answers

2
votes

Technical, definitely not...

Did you heard about Event Storming ? I think it is a good way to found your boundaries...

Bounded context is about language, it is not technical or architectural think, but more about your domain and the words used by your Domain Expert : Greg Young explain-it well in the beginning of this talk

When you are modelling your Domain Model, you have to define your boundaries (for eCommerce, Product is not the same concept with the same attributes in different contexts : catalog, shopping... The same thing about customer... And you don't have to use the same entity for each context, so every context have its specific Ubiguitous language), think about this activity iteratively (sometime Bounded Contexts emerge and are not clearly visible first)

1
votes

As soon as you use both same words to define distinct concepts, you are faced to both bounded contexts.

Suppose an application dealing with movies rental.
If your team (business/developers) talk about "Users" to define users in terms of identity and access, and "Users" too to in terms of Renters, then you would have both bounded context:

  1. IdentityAndAccessContext (managing authentication, roles etc.. technical)
  2. MovieRentalContext (unaware of Users, but Renters)

Bounded context is the reflection of the chosen ubiquitous language.

1
votes

For modeling domain from scratch I think is good decision to start from one bounded context and one module. Than concepts start to conflict or look strange keeped in one module, it's time to separate some concepts into distinct module (or reorganize between modules). Same approach for separating modules into distinct bounded contexts.