I've read a lot of topics about making ef core + ddd working together but they are only show an example where we have only one microservice. I stuck with solution about putting EF Core + DDD right where it's more than one. For example we have 1 database and 2 microservices (identity, schedule). In every service we have to keep own bounded context. Identity service only working with User, Role, ... tables... In opposite, schedule service working with User, Appointment, etc. Also, when we design a domain model we only using properties we need. So, in Appointment service for User entity I only need to use for example Id, NameDetails, Address, ContactInfo when in identity service I use Email, Password, etc. The question is: Should I use the different db context for each microservice? If yes, how I should handle migrations in that case?
Using one database for two or more microservices is a contradiction in itself. A microservice is supposed to be autonomous, meaning it should not share the same database with a different microservice.
If you need to reference a
user-id for instance in two services, you would only store this id, whether it's an integer, a string or any other kind of key.
Your second database will not be able to validate the existence of that foreign key, since it doesn't know about the table where the
Users are stored in.
You would want to create a single db-context for each service, that has it's own migrations and it's own database, when you really want to use microservices.
If you still want to use the same database to do that, you can create many DbContexts that actually point to the same database, but only define a set of entities.
In general there are different levels of domain-driven-design. You can do domain-driven-design without microservices and even without distributed systems. Keywords like
Distributed Systems are all part of
Some resources to read about