Rails Architect MasterClass: Bounded Contexts

In the first week of the course, we had an introduction to the idea of bounded contexts. Currently, in the second week, we are learning more details about this concept and how to apply it in real-life projects.

Bounded context is one of the strategical patterns in Domain-driven design. Most projects are split horizontally as you can see in the image below and it’s called layered architecture. We have different layers for business logic, presentation, and persistence. Number of layers depends on a project but the main idea here is to group our components/classes inside those layers.

Such architecture is perfectly fine, but over time with each new functionality, it’s harder to maintain. The problem here is that we have to focus on the whole system to modify even a small part of it. Bounded context can be described as vertical separation. We can still have layers in each bounded context but in addition, we separate our code vertically into independent units which can work on their own. Thanks to that, we can work on one small part of the system and forget about everything else.

Of course such unit should contain related components which are used to solve one or more problems. Simple examples of bounded contexts are:

• Identity, responsible for users management, authentication, and sometimes authorization.
• Notifications, responsible for sending emails, push notifications, text messages.
• Accounting, responsible for managing finances.
• Ordering, responsible for placing new orders, applying discounts, choosing a payment method, and so on.

How bounded contexts interact with each other?

After introducing bounded contexts we need a way to propagate information between them. In event-driven systems, domain events are published. Domain event represents a fact from our system, for example, OrderSubmitted or ReservationCancelled.

Bounded context can publish their own events and subscribe to events from other contexts. In the example above Ordering bounded context is publishing OrderSubmitted domain event and Notifications bounded context is sending email to the customer as a result.

How can we detect bounded context?

There are many techniques to identify bounded context but unfortunately, there is no silver bullet here. It’s one of those things you need to practice and over time it’s easier to see if some part of the system is a good candidate for a bounded context.

Below you can find my top three techniques I’m using in my daily work:

• Consider if such bounded context can exist as independent microservice. Very often distributed systems are not built as microservices but as distributed monoliths. It basically means that if one service is down then the others can’t work properly. If your bounded context can’t work on their own then it’s not a good candidate.
• Try to imagine your system in the real world, with physical persons. What kind of persons do you need? In most cases, you will see that you need people from different departments and these departments can be represented as bounded contexts.
• Event storming. I will write another blogpost about this technique.

That’s it for now. I hope you liked it. There is a lot of new things here and I only scratched the surface. I think this topic is worth learning. In my opinion, the whole team can benefit from this technique.