Data Domain Pattern

Core Idea

The Data Domain Pattern allows multiple services to share database ownership of common schema elements (tables, schemas) within a bounded context while maintaining joint responsibility for data integrity and evolution. It trades implementation simplicity for managed coupling.

Definition

The Data Domain Pattern is a data management approach where multiple related services share access to common database schema elements (tables, schemas) within the same bounded context. Unlike strict “database per service” isolation, this pattern recognizes that services with high semantic cohesion may benefit from shared data structures when properly governed. It trades implementation simplicity and ACID transaction support for managed coupling between services.

Key Characteristics

• Shared schema ownership: Multiple services jointly own tables or schemas within a bounded context, requiring coordinated schema evolution but enabling simpler data access
• Bounded context alignment: Services sharing data belong to same domain boundary where terms have unified meanings—sharing across bounded contexts is discouraged
• Development-time coupling: Schema changes require coordination among services, creating team dependencies and potentially slowing independent evolution
• Runtime coupling potential: Long-running transactions can block other services accessing shared tables, degrading system responsiveness
• ACID transaction simplification: Transactions spanning entities remain local and atomic, avoiding distributed transaction complexity (sagas, two-phase commit)
• Incremental migration enabler: Used as intermediate step when decomposing monoliths—logically partition tables while planning eventual physical separation

Examples in Practice

• E-commerce bounded context: Catalog, Pricing, and Inventory services share Product tables—tight semantic coupling and consistency requirements justify shared schema
• Banking account management: Account Details, Transaction History, and Balance services access shared Account tables within single domain context
• Monolith decomposition: Extract Order Processing service while connected to shared database with Fulfillment—schema separation planned for later phase

Why It Matters

The Data Domain Pattern represents pragmatic architecture acknowledging not all distributed problems need identical solutions:

• Simplicity over purity: Avoids complex distributed data patterns when services genuinely share semantic domain, reducing operational complexity
• Incremental migration: Enables gradual monolith decomposition without immediately solving every data isolation challenge
• Transaction consistency: Provides ACID guarantees that are architecturally complex in fully distributed systems
• Bounded context enforcement: Restricts sharing within contexts, preventing enterprise-wide shared database anti-pattern while allowing legitimate domain sharing
• Performance: Eliminates network latency and serialization overhead of inter-service calls for data access

Related Concepts

• Bounded-Context — Data Domain Pattern should only be used within bounded context boundaries, never across them

• Coupling — Introduces development-time and runtime coupling between services sharing schema

• ACID — Shared database enables straightforward ACID transactions without distributed transaction patterns

• Eventual-Consistency — Alternative consistency model used when services have separate databases

• Scalability — Shared database limits independent scaling of services’ data tiers

• Fault-Tolerance — Database becomes shared single point of failure affecting all services

• Ford-Richards-Sadalage-Dehghani-2022-Software-Architecture-The-Hard-Parts — Discusses Data Domain Pattern as trade-off between coupling and consistency

• Service-Granularity - Service sizing and data boundary decisions

• Data-Ownership-Patterns - Single-writer ownership patterns

• Interservice-Communication-Pattern - Alternative to shared schema for cross-service data access

• Data-Disintegrators, Data-Integrators - Forces for and against shared schema

• Microservices-Architecture-Style - Distributed architecture context

Sources

• Ford, Neal; Richards, Mark; Sadalage, Pramod; Dehghani, Zhamak (2022). Software Architecture: The Hard Parts: Modern Trade-Off Analyses for Distributed Architectures. O’Reilly Media. ISBN: 978-1-492-08689-5.

  • Chapter on data management patterns and ownership in distributed architectures
  • Describes Data Domain Pattern as shared database with joint ownership between services
  • Available: https://www.oreilly.com/library/view/software-architecture-the/9781492086888/

• Richardson, Chris (2018). “Pattern: Shared database.” Microservices.io.

  • Canonical description of shared database pattern with trade-off analysis
  • Documents development-time and runtime coupling issues
  • Available: https://microservices.io/patterns/data/shared-database.html

• Microsoft (2025). “Data sovereignty per microservice - .NET Architecture.” Microsoft Learn.

  • Discusses data ownership principles and bounded context alignment
  • Explains when shared databases within bounded contexts are acceptable
  • Available: https://learn.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/data-sovereignty-per-microservice

• Tune, Nick (2019). “Sharing Databases Within Bounded Contexts.” Medium - Nick Tune’s Weird Ideas.

  • Practical guidance on when database sharing makes architectural sense
  • Emphasizes bounded context boundaries as critical constraint
  • Available: https://medium.com/nick-tune-tech-strategy-blog/sharing-databases-within-bounded-contexts-5f7ca6216097

• Confluent (2024). “Designing Event-Driven Microservices - Data ownership.” Confluent Developer.

  • Data ownership patterns and bounded context principles
  • Available: https://developer.confluent.io/courses/microservices/data-ownership/

• AWS (2025). “Shared-database-per-service pattern.” AWS Prescriptive Guidance.

  • Incremental migration pattern using shared databases
  • Trade-offs and transition strategies
  • Available: https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-data-persistence/shared-database.html

Note

This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.