[#vaughn-ddddis], on 2nd chapter:
The bounded context encompasses the entities that are relevant to that specific DDD - Subdomains[1]. Everything that's essential for that context should lie there. Everything else should be in another bounded context.
Each bounded context has its own DDD - Ubiquitous Language. So we have context-specific, but very precise terms.
A todo list app could be broken down into the following bounded contexts:
- The list context: contains lists, tasks in lists, assignee (users in the users context)
- The user context: contains user data
- The account context: contains billing data
The list context here would be our core domain (see DDD - Subdomains) since it'd be the HEART of the business.
Look into DDD - Interaction with external bounded contexts for implementation tactics and read DDD - Context mapping for a better conceptual grasp around those interactions.
[1]: Although bounded contexts can contain more than 1 subdomain, it's best practice to limit to 1. So one bounded context contains one subdomain and vice-versa. [#vaughn-ddddis]: Vernon, Vaughn. Domain-Driven Design Distilled. Boston: Addison-Wesley, 2016.