← Back to principles

Data

Bounded contexts own their data

Statement

Bounded contexts should own their data and share through well-designed interfaces

What this means in practice

Each bounded context -- a distinct area of the domain with its own language, rules, and responsibilities -- owns and controls its data. No other context accesses that data directly through shared tables or database-level integration. Instead, data is exposed through well-designed interfaces such as APIs, events, or contracts. Duplication of data across contexts is acceptable and expected; duplication of meaning is not.

Data models are allowed to differ between contexts. A customer record in a billing context may look fundamentally different from a customer record in a support context, and that is by design. Attempting to enforce a single canonical data model across all contexts creates tight coupling and slows every team that depends on it.

Why this matters

When one team relies on another team's tables, control over schema, performance, and evolution is lost. Direct database integration creates hidden dependencies that surface as breaking changes, data corruption, or blocked releases. Owning data behind explicit interfaces allows each context to evolve independently, scale on its own terms, and maintain integrity without coordinating schema changes across the organisation.

A single canonical model often appears efficient on paper but becomes an anchor in practice, constraining how teams model and serve their specific domain needs.

Practices that meet this principle

  • Define clear bounded context boundaries as part of solution design

  • Expose data to other contexts exclusively through APIs, events, or published contracts

  • Prohibit direct database access across context boundaries

  • Accept that the same real-world concept may be modelled differently in different contexts

  • Document integration points and data contracts between contexts

  • Treat cross-context data duplication as a deliberate design choice, not an error to eliminate

Validation

A project meets this principle when:

  • Bounded context boundaries are documented with clear data ownership assignments

  • No cross-context data access occurs through shared database tables

  • OR:

  • Data shared across contexts flows through explicit, documented interfaces