Moving to a new Bounded Context

Dec 01, 2014

Table of contents:

1. What is a Bounded Context?
2. The role of the Identity Bounded Context
3. The role and responsibility of Groups
4. Why choose a separate Bounded Context?
5. Conclusion

A couple of months ago I changed the direction of this building Cribbb series of posts to be more focused on a Domain Driven Design approach to building web applications.

Since that change of direction we’ve covered quite a bit in terms of the “identity” aspect of the application.

So far we have laid the foundation for a rich Domain Layer to encapsulate the business rules of the application. We’ve also looked at the core functionality of registering new users, generating password reminders and we’ve created a follower model for social interaction between users.

All of this functionality fits neatly into the Identity namespace as a unified model. By keeping all of the “identity” focused functionality within this namespace we’ve made the application easier to understand and maintain because all of the related code is in the same place.

The Identity namespace is it’s own Bounded Context. A Bounded Context is the boundary around an area of functionality of an application where the internal consistency is important.

By using different Bounded Contexts, we keep different aspects of the application decoupled.

In today’s article we’re going to be exploring the practicalities of using Bounded Context in a web application, and we’re going to be looking at the next Bounded Context that we will be tackling in this series.

What is a Bounded Context?

A Bounded Context is the boundary around an aspect of the Domain Model that requires internal consistency. When working on a large application it is important to split large models into Bounded Contexts and then to be explicit with how each Bounded Context is related to other Bounded Context of the application.

Using Bounded Context is important for a couple of reasons.

Firstly, it allows you to focus on one particular aspect of the project. Taking on a big gnarly project can be daunting if you don’t split it down into smaller manageable chunks. A Bounded Context should focus on one particular aspect of the project and ignore everything else from the outside world.

Secondly, the boundary around the Bounded Context protects the internal consistency of the model. In large applications you will often find that generic terms become muddled because they mean different things in different contexts. The language and vocabulary within the Bounded Context should be clear and consistent because it does not have to deal with terms and definitions that cover the entire landscape of the project.

And finally, each of the objects within a Bounded Context have a clear scope and set of responsibilities. In large applications you will often find that certain objects attract responsibility from all over the application. These monolithic objects quickly become difficult to use, maintain and test. A Bounded Context will constrain the scope of an object to the focused responsibility of that single aspect of the project. This not only keeps responsibility from leaking in, but it should also stop responsibility from leaking out.

To read more about Bounded Contexts, take a look at What are Bounded Contexts and Context Maps in Domain Driven Design?

The role of the Identity Bounded Context

The role of “identity” is very important when it comes to consumer social applications.

Firstly the on-boarding experience when a new user registers for your application can play a big part in the incentive for that user to stick around and give your application a chance. User churn is a killer when it comes to social applications.

When a user returns to your application after a period of inactivity and is looking to explore once again, the process for resetting their password will again be very important as to whether that user sticks around or becomes frustrated because of a convoluted process.

The ability to allow a user to curate their own experience of your application by following other users has become table stakes in the world of social consumer applications. It almost goes without saying that the ability to follow other users is mandatory in almost all social applications.

And finally, all social consumer applications will have a profile page or the ability for the user to add details about themselves in one way or another. This might be adding a profile picture or connecting to other social applications.

So as you can see, the role of the Identity Bounded Context is very important, despite it not being the “Core” functionality of the application.

Already we have quite a bit of responsibility in this Bounded Context and so it wouldn’t make sense to include non-identity based functionality in this Bounded Context, or to separate these identity based bits of functionality into other semi-related Bounded Contexts.

The role and responsibility of Groups

The next Bounded Context we’re going to be looking at is for Groups.

Cribbb is going to have the concept of Groups that allow users to join them to discover specific content and discussions around a central theme.

A Group will have it’s own identity and properties and it will be the Group that encapsulates the business logic of this aspect of the application.

Groups will have the concept of Members and Admins and it will be the Group that regulates what content and discussions can take place and who can post or comment on them.

Users will be able to join Groups to be come a Member and certain Users will become Admins of one or more Groups.

Why choose a separate Bounded Context?

I think it’s important to separate the functionality of Groups into it’s own Bounded Context for a couple of reasons.

Firstly, if we aren’t strict about the scope of Bounded Contexts we can quickly find ourselves in a position where certain aspects of the application have too much responsibility. At some point we have to draw the line as to what is allowed in and what is kept out.

Secondly, the context of a User is different in the Identity Bounded Context than it is in the Groups Bounded Context. In the Identity Bounded Context, the User is the focal point of the functionality and so basically everything will flow through that key Entity. In the Group Bounded Context, it is the Group Entity that is the most important.

Thirdly, we don’t have the concept of Users in the Group Bounded Context, instead we have a more granular definition of Members and Admins. Members and admins will still be both “Users”, but they will likely have different roles and responsibilities within this Bounded Context.

Conclusion

As we progress through the development of Cribbb, we will encounter a number of inflection points as we move to new Bounded Contexts.

Now that we’ve finished looking at the Identity Bounded Context, it’s time to move to the Groups Bounded Context.

Modelling an application as separate Bounded Contexts is important for a couple of reasons. Firstly, it keeps everything consistent within the boundary, secondly, it means your code is logical and consistent and thirdly, it forces you to be strict on the scope of functionality of any one particular part of your application.

Next week we will continue to look at building out the Groups Bounded Context.

This is a series of posts on building an entire Open Source application called Cribbb. All of the tutorials will be free to web, and all of the code is available on GitHub.