24 lines
1.2 KiB
Markdown
24 lines
1.2 KiB
Markdown
# 10. Single ownership for services
|
|
|
|
Date: 2021-10-18
|
|
|
|
## Status
|
|
|
|
Accepted
|
|
|
|
## Context
|
|
|
|
There are generally three options for persisting data. Single ownership, joint ownership, or common ownership.
|
|
|
|
## Decision
|
|
|
|
We will go for single ownership for all our databases. That is, each domain/service that will persist data will have its own database of which that service will be the sole owner. Any service that wants to write data to or read data from a database other than its own will have to go through the database's owner.
|
|
|
|
Having single ownership preserves the bounded contexts and allows each service to be its own architectural quantum. This allows the services to stay decoupled and therefore can allow us to also decouple the scope of the architectural characteristics of each bounded context. We can for example more easily scale each service up and down as we can also scale the databases (size, performance) for each service.
|
|
|
|
## Consequences
|
|
|
|
Having a distributed architecture and asynchronous communication along with single ownership will force us to rely on eventual consistency.
|
|
|
|
Moreover, this decision could negatively impact performance as we add latency to data access across bounded contexts.
|