Defining Bounded Contexts

DDD(Domain-Driven Design) brings domain experts and developers together.[¹]

The goal of DDD is to develop software that reflects the mental model of the business experts.

We developers are technical thinkers. Technical solutions come easy for us. It’s not that thinking is terrible. There are times when thinking in technical terms; less is better.

The business core Domain is a part of the business Domain that is of primary importance to the organization’s success.

The business core Domain is what makes the business unique. Each business sub-domain maps to a department.

Bounded Context

A bounded context is a complete, well-defined business domain model.[¹]

In the broad sense, a business domain is what an organization does and the world it does it in.

When using DDD, the goal is to create a Bounded Context. It is a desirable goal to align business sub-domains or departments one-to-one with Bounded Contexts.

Bounded context should be limited to the language that your team speaks and develops and then is reflected in a domain model.

At the implementation, level bounded contexts are deployable units of the software. In Ruby, a Bounded context might be a gem.

The internal structure of the gem can be defined with namespaces. e.g., Sales, Marketing.

The architecture of a software system is the shape given to that system by those who build it. The organization’s social network influences the best structure for a software system.

The final structure of any system reflects the team’s communication mechanism. — Conway’s Law[²]

— -

[¹]: Vaughn Vernon(2013): Implementing Domain-Driven Design (https://www.amazon.com/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577)

[²]: Conway’s Law (https://en.wikipedia.org/wiki/Conway%27s_law)