What should be primary guideline when defining a bounded context?

Question

When defining bounded contexts of a Domain, what should be a primary guideline:

• departments (Sales/Manufacturing/Warehousing), where each department has a common context (https://softwareengineering.stackexchange.com/a/316829/226099)
• work load, for example Sales BC could be broken down to Client Administration, Billing, Sales agent BCs in order to have less complex domain models and be able to scale more easily

How narrow should a context of a bounded context actually be? Is it only up to us to define BCs following the current and future needs of a domain, or there is a common rule to follow when defining BCs?

Answer 1

"Bounded context should be relatively small, but large enough only to capture the complete ubiquitous language of the isolated business domain, and no larger"

Answer 2

In my understanding, primary function of a bounded context is to encapsulate a common language used by a group of users. This is the main tool that enables reflecting already used terminology in software abstractions instead of creating unnatural abstractions to satisfy all users.

IMO primary guideline for drawing context boundaries would be to not think about it too much. It's all about already used terminology, so you have to work with the users, listen to their language, ask them for meaning, and draw a boundary when it's needed (or just natural).

As far as specific guidelines go, I can think of the following:

1. Two entities should definitely be separated by a context boundary if they have the same name but different meaning,
2. A set of terms (let's call it A) known by a group of users should probably be separated from its anti-set (whole domain minus A).
3. Keeping bounded contexts self-sufficient (able to provide functionality on their own) enables moving them to different processes, (micro-)services, or even separate systems.

After the domain is created, you could compare it with company's departments (or anything else) as a part of a post-mortem analysis.

Answer 3

A bounded context contains a domain model. So typically, a bounded context represents an application or micro/service.

A large application such as an ERP suite, could have multiple bounded contexts representing the different applications in the suite, e.g. CRM, Accounting, Procurement, HR.

If modifying part of an existing application, it can be common to recognize the existing, unchanging part as one bounded context, and the new part as its own bounded context.

Overlap between bounded contexts, i.e. sharing part of the model, is rarely undertaken successfully, and these days is at odds with more modern service/microservice architectures.