maece/HSG-MCS-HS21_tapas
1
0
Fork 0
Code Issues 14 Pull Requests Packages Projects Releases 6 Wiki Activity

Update 0010-single-ownership-for-services.md

Browse Source
This commit is contained in:
Julius Lautz 2021-12-23 11:47:50 +01:00 committed by GitHub
parent fff7c5e816
commit 97990cbe29
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
TAPAS-Final/doc/architecture/decisions/0010-single-ownership-for-services.md
View File

@ -12,9 +12,9 @@ There are generally three options for persisting data. Single ownership, joint o
## 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