How can you divide your monolith into micro pieces while all your data model and their RELATIONS defined in a one large module. The models strongly related to each other and they are defined as an exactly one big model.
If some data have a hard relationship with each other inherently, then I guess they are supposed to be together. I think the benefit of having a data model schema is that you can identify that relationship quite clearly. Therefore, if you want to split your monolith into micro pieces, you can start to do it from the schema(data layer). Martin Fowler has another post about it you could check it out:
This is where things get separated between monolith and microsrv. In microservices env you cannot keep it DRY. To some degree you will have data duplication.
Say you have a social network. You have 2 microsrv. When someone coments you need to notify the post owner. How you do it?
In most of the case you have the user id, right? The author id. So on the notification service you will do a query with that id to get the rest of the data: email or phone number.
The problem is that data modeling in most of the cases is done all wrong by logical scope not business scope.
It's a phone number or emal, than it should definetly stay on a service called user manager, right? No? Data should be atomic and be store where needed.
But to sync that? Well that is a different story. This is where event driven design comes into place. I will not dive into it because it a topic many people don't like because it's "hard".
I use graph whenever possible and I am happy. No tables just data types. Table border creats confusion. In my app an USER can be called to PHONE NO. and weres size X on CLOTHES, drives CARS. Done, simple and stress free :)
typos
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
How can you divide your monolith into micro pieces while all your data model and their RELATIONS defined in a one large module. The models strongly related to each other and they are defined as an exactly one big model.
If some data have a hard relationship with each other inherently, then I guess they are supposed to be together. I think the benefit of having a data model schema is that you can identify that relationship quite clearly. Therefore, if you want to split your monolith into micro pieces, you can start to do it from the schema(data layer). Martin Fowler has another post about it you could check it out:
How to break a Monolith into Microservices
This is where things get separated between monolith and microsrv. In microservices env you cannot keep it DRY. To some degree you will have data duplication.
Say you have a social network. You have 2 microsrv. When someone coments you need to notify the post owner. How you do it?
In most of the case you have the user id, right? The author id. So on the notification service you will do a query with that id to get the rest of the data: email or phone number.
The problem is that data modeling in most of the cases is done all wrong by logical scope not business scope.
It's a phone number or emal, than it should definetly stay on a service called user manager, right? No? Data should be atomic and be store where needed.
But to sync that? Well that is a different story. This is where event driven design comes into place. I will not dive into it because it a topic many people don't like because it's "hard".
I use graph whenever possible and I am happy. No tables just data types. Table border creats confusion. In my app an USER can be called to PHONE NO. and weres size X on CLOTHES, drives CARS. Done, simple and stress free :)
typos