Data ownership
Data sovereignty connects data to the building block, which governs their business meaning and change. Other building blocks access it via agreed contracts.
- OwnersExactly one module per data type.
- ContractOthers only read what is released.
- Own factIts own meaning instead of mere copy.
Context
Why this is important
Without data sovereignty, several modules change the same data under their own assumptions, and no one is responsible for the result. Shared storage does not clarify this. How boundaries are enforced in code shows module boundaries; the temptation of the common database is dealt with by the modular monolith. This is about the allocation itself.
This building block explains business responsibility for data. For technical transaction limits, see Transaction Limits.
At a glance · One owner per dataset
Who owns which type of data?
In the modular monolith, tables are located in a database, but remain assigned to individual modules. Shared storage does not override data sovereignty.
This is how you read the picture
- Owners The cell “owns and writes” appears exactly once in each line.
- Contract The cells “read about contract” show who receives data without changing it.
- Own fact The highlighted line: The agreed price in B-1042 belongs to the order, not the catalogue.
| Data type | Catalogue | Basket | Order | Payment | Inventory | Shipping | Invoice |
|---|---|---|---|---|---|---|---|
| No access | No access | Owns and writes | No access | No access | Read about Treaty | Read about Treaty | |
| No access | No access | Read about Treaty | Owns and writes | No access | No access | Read about Treaty | |
| No access | No access | Read about Treaty | No access | Owns and writes | No access | No access | |
| No access | No access | Read about Treaty | No access | No access | Owns and writes | No access | |
| Owns and writes | Read about Treaty | No access | No access | No access | No access | No access | |
| No access | No access | Owns and writes | No access | No access | No access | Read about Treaty |
Mission and statusOwns and writes: Order
Shipping reports on the contract, the order decides on its status.
Writer by type of data1
Each type of data has exactly one writer; others read about the contract, and the rules remain protected.
Benefits & limitations
Helps if:
- Multiple building blocks with shared data needs benefit from a designated business owner who assigns rules and binding changes.
- Ownership contracts minimise direct dependencies on internal storage forms across services and modules.
- A clear owner makes the relevant source recognisable in derived reading or analysis views.
Boundaries
- An owner can become a bottleneck at a high update rate; measure throughput and split responsibilities only where domain rules allow it safely.
- Derived copies become stale and are not authoritative; an independently owned fact, such as the agreed price, is authoritative for its own purpose.
- Reports spanning several owners need dedicated read views rather than joins over other modules' tables; see CQRS.
In practice
- Determine the owner for each data area and anchor this jurisdiction in code and access rights. Only the owner makes binding decisions on changes and business validity.
- Mark published read views as derived and document their source and freshness. Submit changes through the owner's contract rather than reproducing its internal storage.
- Review ownership when boundaries change. Bounded Context defines domain boundaries; Shared Database describes coupling through shared storage.
Read the detailed explanation
A data owner is responsible for the meaning, rules and authoritative changes within a business data area. Other building blocks read approved views or request changes through the owner's contract. Invariants can then be enforced at one authoritative point.
Ownership includes lifecycle, access, migration and correction. Derived views may contain the same information but do not automatically become additional write authorities. Their source and freshness must be visible so consumers choose the authoritative source correctly.
Bounded Context defines the domain scope; Shared Database shows how shared storage can blur this responsibility technically.
Database per Service applies this approach to separate services. A modular monolith can use a shared database in which each module owns its tables.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
Who owns stock and reservation, and who reads it?
View the solution with justification
The camp owns and writes them. The order reads about the contract and requests reservations.
ApplyingTransferred to a new situation
The catalogue lowers the cup price 19,95 EUR. What happens to the price in B-1042?
View the solution with justification
He shall remain with 24,95 EUR. The agreed price is a separate fact of the order; the 19,95 EUR is only valid for new purchases.
EvaluateWeighing an alternative
The invoice wants to directly join order and payment tables for a report. How do you rate that?
View the solution with justification
It is conveniently and quickly built, but ties the bill to foreign table forms and bypasses the owners. Better: own reading view or a contract of the owners.
Explore further
These building blocks continue the thoughts of this page.
References
- microservices.io · Database by Service (opens in new tab)Describes data responsibility, API access, and query consequences.
- Martin Fowler · Microservices (opens in new tab)Describes service limits, data responsibility and organizational consequences.
- Martin Fowler · Bounded Context (opens in new tab)Explains model boundaries and relationships between different specialist models.