Update 0010-single-ownership-for-services.md
This commit is contained in:
parent
fff7c5e816
commit
97990cbe29
|
@ -12,9 +12,9 @@ There are generally three options for persisting data. Single ownership, joint o
|
||||||
|
|
||||||
## Decision
|
## 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 owen will have to go through the database's owner.
|
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 quanta. 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.
|
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
|
## Consequences
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue
Block a user