In DDD terminology this is called persistence ignorance. It is an important principle because it forces you to focus on modeling the domain accurately, without worrying about the representation of the data in a database.

Letting classes drive the design can be just as dangerous as letting a database drive the design—again, you’re not really listening to the requirements.

. It’s tricky to create a truly decoupled microservice architecture: if you switch one of the microservices off and anything else breaks, you don’t really have a microservice architecture, you just have a distributed monolith!

Applicatives are similar to monads; but rather than chaining monadic functions in series, an applicative allows you to combine monadic values in parallel.

Bounded contexts must own their own data store.

queries and commands tend to evolve independently and therefore shouldn’t be coupled

In particular, you can have a read store that contains aggregated data from many bounded contexts, which is very useful for doing reports or analytics

One thing we should not do is model the output of a business rule in the domain

It can subscribe to events from the other contexts and update the state accordingly. Any queries about the status would then go directly to this context.