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 allows multiple related services to share access to common database schema elements within the same bounded context. Unlike strict “database per service” isolation, it recognizes that services with high semantic cohesion may benefit from shared data structures when properly governed.
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 and atomic transactions
- Bounded context alignment: Services sharing data must belong to the same domain boundary—sharing across bounded context boundaries is strongly discouraged
- Development-time coupling: Schema changes require coordination among all services accessing the schema, creating team dependencies
- Runtime coupling potential: Long-running transactions can block other services accessing shared tables
- ACID transaction simplification: Transactions spanning entities remain local and atomic, avoiding distributed transaction complexity
- Incremental migration enabler: Used as an intermediate step when decomposing monoliths
Why It Matters
The Data Domain Pattern represents pragmatic architecture acknowledging that not all distributed problems need identical solutions:
- Simplicity over purity: Avoids complex distributed data patterns when services genuinely share a semantic domain
- 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-patterns
The primary risk is that shared schemas make independent scaling of each service’s data tier harder and introduce a shared single point of failure.
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
- Eventual-Consistency — Alternative consistency model when services have separate databases
- Scalability — Shared database limits independent scaling of services’ data tiers
- Fault-Tolerance — Database becomes shared single point of failure
- Software Architecture - The Hard Parts - Ford, Richards, Sadalage & Dehghani - 2022 — 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
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. Available: https://www.oreilly.com/library/view/software-architecture-the/9781492086888/
-
Richardson, Chris (2018). “Pattern: Shared database.” Microservices.io. Available: https://microservices.io/patterns/data/shared-database.html
-
Microsoft (2025). “Data sovereignty per microservice - .NET Architecture.” 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. Available: https://medium.com/nick-tune-tech-strategy-blog/sharing-databases-within-bounded-contexts-5f7ca6216097
-
Confluent (2024). “Designing Event-Driven Microservices - Data ownership.” Available: https://developer.confluent.io/courses/microservices/data-ownership/
-
AWS (2025). “Shared-database-per-service pattern.” AWS Prescriptive Guidance. 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.