Bounded context/domain-driven design

As part of the application design, the business domain needs to be broken down into smaller subdomains or business capabilities. We need to carefully examine the business entities and their attributes to define service boundaries. For example, in the case of customer ID entity, the address of the customer might be integral to the customer. Within the context of the application, address maintenance might be a separate activity and might need to be handled separately. Similarly, customer preferences or shopping habits might be required for personalization. In this case, the personalization engine is more interested in this set of attributes.

Should we be slapping together one big customer service having all kind of attributes or can it be divided based on the perspectives derived from the business? These different perspectives are what led to the definition of bounded context as part of the domain-driven design.

The bounded context is a domain-driven design paradigm that helps to add a seam and create service groups. Bounded contexts work in solution-space to indicate that the services are related and belong to a common functional domain. It is built by one team that works with one business unit as per Inverse Conway's law. A bounded context may communicate with the other services/business capabilities through:

• Exposing internal APIs or services
• Emitting events on the Event Bus

A bounded context may have its own data store common to services or adopt a data store per service paradigm.

Each bounded context has a life of its own and forms a product. Teams are organized around these bounded contexts and they take the full responsibility of the full stack implementation of the services. The teams are cross-functional and bring skills from development, testing, user experience, database, deployment, and project management. Each product might be split into smaller sets of services that communicate asynchronously with each other. Remember, the focus is not on a set of functionalities but rather on business capability.

We start building our services around business capabilities. The service owns its business data and functionality. The service is the master of such data, and other services cannot own any of this service data.