Data Boundaries and Ownership

Data ownership is where many service boundaries either become real or collapse into theater. Chapter 6 turns the usual slogans into practical boundary discipline: why shared databases break autonomy, what “one service, one source of truth” really means, how to reason about copied and derived data correctly, and why large or legacy data shapes create pressure on otherwise clean boundaries.

Read the lessons in order. The first makes the shared-database anti-pattern concrete. The second explains authoritative ownership without pretending data can appear only once. The third separates reference data, derived data, and read models so duplication can be judged correctly. The fourth covers data gravity and why some boundaries are harder to keep clean in practice than they look on a diagram.

If a proposed service still depends on “just one direct table read” to stay workable, Chapter 6 is the place to challenge that shortcut before it hardens into architecture.

In this section

• Why Shared Databases Break Service Autonomy
  A practical lesson on why shared schemas and direct cross-service table access undermine ownership, release independence, and real service boundaries.
• One Service, One Source of Truth
  A practical lesson on authoritative ownership, what “source of truth” really means, and how to avoid confusing copied data with business authority.
• Reference Data, Derived Data, and Read Models
  A practical lesson on how to distinguish authoritative data from copied, derived, and query-optimized data so duplication can be judged correctly.
• Data Gravity and Boundary Pressure
  A practical lesson on how large datasets, high transaction rates, legacy integrations, and reporting needs create pressure that can distort otherwise clean service boundaries.