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.

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.

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.

I’m a Ruby on Rails developer :)

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store