Organizing around bounded contexts

- Melvyn Conway, 1967

Generally, the organization structure contributes heavily to the design of the application. Therefore, bounded contexts should never be identified on the basis of the existing structure of the organization. Instead, the organization must be structured around bounded contexts such that the entire team can work on a service in isolation.

A typical organization, working on a monolithic application, is built around layers of presentation, business logic, and persistence, as shown in the preceding diagram. They tend to have a separate team of UI designers and UI/UX experts for the presentation layer, a team of backend developers to implement the domain model, and a team of database administrators to create a database for developers to access. Such an organization structure is ideal for an application with a smaller set of business capabilities.

Once the application grows, any changes to the application require communication to be made across the team of UI engineers, backend developers, and database administrators. Often, such communication leads to so many back-and-forth exchanges involving design documents and specification changes that it becomes overwhelming for the teams to translate the requirements correctly to the implementation. Such communication overhead adds delays to the project and brings down the productivity of the entire team working on the product as a whole.

Bounded context, if identified correctly, solves this problem by localizing the team of UI developers, backend developers, and database administrators to focus on a single business capability. Such boundaries make sure that the communication between the teams is bounded by a fixed contract that is set at the service level. This makes it possible to reduce a considerable communication overhead, as any changes made to a service are confined within the team working on the service. For example, the localized team of User Service and Orders Service will communicate only to discuss the service APIs that the user service is exposing for Orders Service to get the customer details. Since any changes to the customer schema or the orders schema should not impact each other as per the definition of bounded context, it is not required to communicate such changes to the other service.