Hi, first of all let me really thank you for your videos. Needless to say they're very insightful and at the same time very straight forward... I've been watching them all, from the beginning, eagerly. I have, though, a small, probably silly, question. I remember you referred to the sharing of a database among split services as sort of an anti-pattern. One of the reasons was that, for an ORM, context-wise, they assume they're the only ones fully in control of the DB (which wouldn't be true, in this case). How would you mitigate any problems in this scenario? or is it just a momentary risk you have to take in the meantime you tweak the service's size and migrate the DBs? By these risks I mean the ones that come with sharing the DB among services.
The goal with Microservices is to have tight bounded contexts, where each service owns its own data. However, due to dual ownership, database artifacts such as foreign keys and views, sometimes we cannot split a database that fine-grained. In these cases we do need to share data. The risk is mitigated by having NO MORE THAN 6 services share a data context, and also having strong governance for write privileges. Not optimal, but pragmatic.
Hi, first of all let me really thank you for your videos. Needless to say they're very insightful and at the same time very straight forward... I've been watching them all, from the beginning, eagerly.
I have, though, a small, probably silly, question. I remember you referred to the sharing of a database among split services as sort of an anti-pattern. One of the reasons was that, for an ORM, context-wise, they assume they're the only ones fully in control of the DB (which wouldn't be true, in this case). How would you mitigate any problems in this scenario? or is it just a momentary risk you have to take in the meantime you tweak the service's size and migrate the DBs? By these risks I mean the ones that come with sharing the DB among services.
The goal with Microservices is to have tight bounded contexts, where each service owns its own data. However, due to dual ownership, database artifacts such as foreign keys and views, sometimes we cannot split a database that fine-grained. In these cases we do need to share data. The risk is mitigated by having NO MORE THAN 6 services share a data context, and also having strong governance for write privileges. Not optimal, but pragmatic.
Very good pattern. Thank you.