Bounded context find the boundary?

Question

In my current project (e-commerce website), we have different Bounded Context like: billing, delivery or payment in our checkout process.

On top of this, depending on what the customer will buy, the checkout process will be different. So depending on the content of her cart the number of steps in the checkout process can be different, or we won't/will ask her for certain informations.

So should one create a different bounded context for each different type of checkout process ?

For example, the Order aggregate root will be different depending on the checkout process EticketsOrder (in this context we don't need a delivery address so we won't ask one to the user) Ticket BillingAddress

ClothesOrder (in this context we need a delivery address and there will be an additional step in the checkout process to get this) Clothes BillingAddress DeliveryAddress

This separation will imply to create two different domain entities even thought they have similar properties.

What's the best way to model this kind of problem ? How to find the context boundary ?

Answer 1

It appears as though you may have missed a bounded context. When this happens one tends to try and fit the functionality into an existing BC. The same thing happens to aggregate roots. If something seems clumsy or it doesn't make sense try to see whether you haven't missed something.

In your example I would suggest a Shopping BC (or whatever name makes sense). You are trying to fit your checkout process into your Order BC. Your Shopping BC would be responsible for gathering all the data and then shuttling it along to the relevant parts.

The product type selected will determine whether a physical delivery is required.

Hope that helps.

Answer 2

A bounded context is chiefly a linguistic boundary. A quote from the blue book (highlighted key part):

A BOUNDED CONTEXT delimits the applicability of a particular model so that team members have a clear and shared understanding of what has to be consistent and how it relates to other CONTEXTS. Within that CONTEXT, work to keep the model logically unified, but do not worry about applicability outside those bounds. In other CONTEXTS, other models apply, with differences in terminology, in concepts and rules, and in dialects of the UBIQUITOUS LANGUAGE.

A question to ask is whether the different types of orders created are entirely distinct aggregates, or are they all order aggregates with different values. Is there a need to consider order as a whole regardless of how they were created? I've build and worked with ecommerce systems where different types of orders were all modeled as instances of the same aggregate, just with different settings and there were no linguistic issues. On the other hand, the orders in your domain may be different enough to warrant distinct contexts.

I often consider BC boundaries from the perspective of functional cohesion. If you segregate orders into two BCs will there be a high degree of coupling between them? If so, that may be a sign that they should be combined into one BC. On the other hand, if the only place that the BCs interact is for reporting purposes, there is no need to combined them.