Why this matters
Boundary implementation patterns
- Identifiers: Prefer context-native IDs; map via reference tables or ACLs. Avoid global mega-IDs unless truly stable across contexts.
- Events: Immutable, versioned; add-not-break fields; keep payloads domain-specific.
- Queries across boundaries: Use published read models or replicated caches, not direct DB joins across contexts.
- Anti-corruption: Translate names, units, enums, and state machines to avoid model leakage.
Analytics and data platform angle
- Source-aligned vs. domain-aligned: Raw zones reflect source systems; curated zones reflect business domains.
- Data products: Each domain publishes owned, discoverable datasets with SLAs, lineage, and contracts.
- Schema evolution: Use additive evolution; deprecate with grace periods and version tags.
Checklists
Boundary litmus checklist
- One owner team, one backlog
- Clear ubiquitous language documented
- Separate data store or clearly partitioned schema
- Contracts defined and versioned
- Most changes do not require cross-team coordination
- Testing strategy covers contract tests and consumer-driven contracts
Contract checklist
- Purpose, owner, consumers listed
- Schema with types, nullability, semantics
- Versioning and compatibility policy
- Identifiers and mapping strategy
- SLAs: freshness, latency, availability
- Data quality expectations and validation rules
Common mistakes and self-check
- Mistake: Shared "User" model across all contexts. Fix: Each context defines its own User view; share only IDs via contract.
- Mistake: Direct DB joins across contexts. Fix: Use published datasets or APIs; replicate via events if needed.
- Mistake: Leaky enums/state. Fix: Translate via ACL; keep internal enums private.
- Mistake: Over-centralized global ID. Fix: Context-local IDs + mapping tables.
- Mistake: Analytics rewriting source rules. Fix: Keep business logic in upstream domain; analytics consumes facts/events.
Self-check: If you rename a field internally, do consumers break? If yes, boundary or contract is weak.
Who this is for
- Data Architects, Analytics Engineers, Platform/ML Engineers who design domain-aligned data products
- Tech Leads coordinating multiple teams and data contracts
Prerequisites
- Basics of conceptual/logical modeling (entities, relationships)
- Familiarity with domain-driven design terms
- Understanding of data contracts and event-driven concepts
Learning path
- Before: Entities and relationships, normalization vs. denormalization
- This topic: Domains, bounded contexts, context mapping, contracts
- After: Event modeling, data product design, schema evolution strategies
Practical projects
- Design a context map for a subscription SaaS (Signup, Billing, Entitlements, Support)
- Define an OrderPlaced event contract with versioning and quality rules
- Create a domain-aligned curated data set for Payments with clear ownership and SLA
Exercises
Try these now. You can compare with solutions. Then take the Quick Test. Note: The test is available to everyone; only logged-in users will have progress saved.
Exercise 1: Map domains and boundaries for a ride-sharing platform
Scope: Rider app, Driver app, Trip matching, Pricing, Payments, Support.
- List candidate bounded contexts.
- Propose key aggregates per context.
- Define 3 contracts (events or APIs) between contexts.
- Note where an anti-corruption layer is needed.
Exercise 2: Stabilize analytics domains from messy lake
Scenario: A data lake with mixed tables: users, trips, charges, surge_table, driver_status, tickets. Build domain-aligned curated datasets.
- Propose domain boundaries for curated zone.
- Define identifiers and mapping strategy.
- Write an additive change you might make and how you’d version it.
Exercise checklist
- Each context has one owner and clear language
- Contracts list fields, types, and versioning
- IDs are local; mappings are explicit
- ACLs placed where models diverge
Mini challenge
Pick a feature request: “Show live driver ETAs on the Rider app.” Decide which contexts change, and propose the contract added or updated. In one paragraph, justify your boundary choices.
Next steps
- Refine your context map with stakeholders; validate with example events
- Create a consumer-driven contract test for one interface
- Move to event modeling and schema evolution for your key domains
Take the Quick Test
When ready, take the Quick Test below. You can retake it anytime. Progress is saved for logged-in users.