2

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?

alexqq
  • 129
  • 1
  • 10

2 Answers2

3

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 Aggregates, Commands and Events, Distributed Systems are all part of domain-driven-design.

Some resources to read about domain-driven-design

https://stackoverflow.com/a/1222488/5397642

https://martinfowler.com/bliki/DDD_Aggregate.html

https://medium.com/withbetterco/using-aggregates-and-factories-in-domain-driven-design-34e0dff220c3

https://dev.to/designpuddle/apps--microservices--what-you-need-to-know-autonomy-and-the-challenges-you-will-face-39e1

alsami
  • 8,996
  • 3
  • 25
  • 36
  • Thank you for your answer. About "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." - Is it possible to solve this problem or this is not a quite a problem ? I mean, if for another microservice I will create it's own database and for example it will have the table "Appointment' which keeps a field UserId. How would I be able to validate that UserId has a correct value before adding a row into this table ?Can I do this only on the server side? – alexqq Jan 21 '19 at 16:55
  • You could for instance provide an API to validate the existence. So when generating an appointment for an user, you would call the service that owns user data. There are many ways to do so, this would be one. – alsami Jan 21 '19 at 17:46
0

I think that in this particular case User in Identity service isn't the same as User in Appointment service. I would make new Entity called, for example Person(with attributes such as NameDetails, Address, ContactInfo, DateOfBirth etc..) , in Appointment service and save it in separate database for that service (2 databases 2 services).

desertnaut
  • 57,590
  • 26
  • 140
  • 166
TLamp
  • 61
  • 3