Separate Read-Write Database

[m-khooryani]

Hi everyone!

In this project, the same database has been used for both read and write.
If we separate the database, what changes we would deal with?
Write model could be updated efficiently with normalized data, then send an event to update the Read database. I mean bigger aggregates with denormalized data to prevent join from tables. consider using CosmosDb, since documents join is not supported, the approach in this project(joining data) does not work.

For example, should we use separate entities for the read database? if yes, should be placed in the Domain layer?
Also, Commands, Queries, Entities, and other concepts would repeat again for reading models?
Should we use separated DbContext?
And what are the challenges with this approach?

[kgrzybek]

Hi @m-khooryani

If you will have separate databases for write and read you will have an Eventual Consistency issue on each use case. It means you will have a stale Read Model for some amount of time and you need to handle it somehow :) I would say it is not a good idea to do that on the whole system level - you should apply it only to places where it is needed (performance and scalability) because that way you lose some level of consistency.

About ReadModel implementation - most concepts of Domain Layer in DDD terms are related to states mutation (Aggregates protects invariants, entities are to track objects in time) so they are not needed in ReadModel. ReadModel is just an optimized data structure especially for reads - it is a projection of the state of your system. ReadModel should not have business logic - it should be dumb.