Guidelines for Defining Microservice Model Boundaries and Sizes Using Bounded Contexts

When determining the model boundaries and size of each microservice, the goal is not to achieve the finest possible granularity but to create the most meaningful separation guided by domain knowledge, focusing on business capabilities rather than sheer scale. If a specific area of a large, highly dependent application requires strong cohesion, it may be best represented as a single microservice. Cohesion helps decide how to split or combine services, and the appropriate size is refined iteratively as domain understanding grows.

Sam Newman, a recognized authority on microservices and author of *Building Microservices*, stresses that microservice design should follow the Bounded Context (BC) pattern from Domain‑Driven Design (DDD). A BC can consist of multiple physical services, and vice‑versa.

Domain models with specific entities are applied within a BC or microservice. Business continuity defines the applicability of the domain model and gives teams a clear, shared understanding of what must stay cohesive and what can be developed independently.

Conway's Law, which states that a system mirrors the social boundaries of the organization that creates it, can be used as a design cue; sometimes organizations may deliberately invert this law to shape service boundaries that align with desired business processes.

To identify bounded contexts, the DDD pattern called Context Mapping is used. Context maps reveal the various contexts and their boundaries within an application, showing that each small subsystem may have its own context. A BC is autonomous, contains detailed domain information, and defines integration contracts with other BCs—mirroring the definition of a microservice.

In large applications, domain experts from different domains (e.g., catalog, shipping, ordering, CRM) will name entities differently and may require different attributes. Trying to enforce a single unified vocabulary across all domains is impractical; instead, each domain should retain its own terminology, and BCs (implemented as microservices) clarify where specific terms apply.

If domain models have few strong relationships and typical operations rarely need to aggregate data across multiple domains, the boundaries and sizes of each BC are likely correct.

The ideal answer to "how big should a microservice's domain model be?" is that it should be as independent as possible, allowing work without constantly switching to other contexts.

Figure 10 illustrates an online meeting‑management system where the same entity appears as "User", "Buyer", "Payer", or "Customer" depending on the bounded context. Some entities exist only in one microservice (e.g., Payments in the Payment microservice), while others share the same identifier across multiple services but have different attributes based on the context.

Figure 11 shows how a traditional data model is decomposed into multiple domain models.

When decomposing a traditional data model across bounded contexts, the same identifier can represent different entities with distinct attributes in each context (e.g., a user as a regular user in the meeting‑management service, as a buyer in the ordering service, or as a payer in the payment service). Each service only stores the subset of data it needs, reducing duplication.

Sharing the same user identifier across services brings benefits such as reduced redundancy and the possibility of a master microservice that owns the canonical data for each entity, handling updates and queries centrally.