Shared kernel

As explained in Collaborative Software Design: How to facilitate domain modeling decisions

A shared kernel is a deliberately bounded subset of a domain model, together with relevant code or database design, that multiple teams agree to share.

A shared kernel is a deliberately bounded subset of a domain model that multiple teams agree to share. It includes the relevant code or database design, and changes require consultation with every affected team. section 10.3.1

Four teams sharing one model

During a proposed monolith-to-microservices transition, four teams owned separate bounded contexts but depended on one shared model. Any change required discussion with the other teams and could force changes across their models, reducing autonomy and slowing releases. section 10.3.1

Use a shared kernel deliberately:

• Keep the shared subset concise and give it a clearly defined boundary. section 10.3.1
• Treat changes to the kernel as cross-team decisions requiring alignment. section 10.3.1
• Weigh consistency against autonomy, coordination overhead, and time to market. section 10.3.1

Figure 10.8 A shared kernel pattern. Four teams each own their own bounded context, but they share a model. Every time that model is affected, they need to talk to the other teams to change it.

Use the diagram to see how team-owned bounded contexts depend on one shared model and why changes require coordination. section 10.3.1

How Collaborative Software Design: How to facilitate domain modeling decisions covers it

How deep it goes

Defines the boundary and governance of a shared kernel, then traces its effects on coordination, autonomy, and delivery speed.

Examples

Uses a four-team shared model during a proposed monolith-to-microservices transition and an accompanying relationship diagram.

What you can do after

Evaluate whether shared consistency justifies the coordination required to change and release dependent models.

How it connects

Connects domain-driven design, bounded contexts, microservices architecture, monolithic systems, team autonomy, and time to market.

liveBookmanning.com

Read Collaborative Software Design: How to facilitate domain modeling decisions on liveBook Get the book at manning.com

Related concepts

• domain modelpart of · A domain model is a software representation of the concepts, entities, relationships, rules, and behavior of a problem or business domain.
• autonomycontrasts with · Autonomy is the capacity or degree to make decisions and act independently within a defined responsibility or set of limits.

This explainer was generated by Manning's knowledge graph from the text of Collaborative Software Design: How to facilitate domain modeling decisions. The section links point to the parts of the book it draws on.