How to split monolothic application into microservices when most operations on one aggregate?

0
votes

I am splitting a monolothic application into microservices based on this schema https://gist.github.com/lithdew/0b6f892b927333f76dc4bdcf34e4d9ec

Following DDD, I found 4 aggregates for this schema: User, JobTitle, Skill and Course. So there should be 4 microservices corresponding Account, JobTitle, Skill and Course.

The tricky thing is when I come across all APIs providing to Front End, 90% of them are related to User dependent Entities such as user_skills, user_job_titles ... If I follow the DDD, then Account microservice would be very big, most of logic will go inside this microservice and the others would be tiny. Base on this, I come up with 2 solutions:

  1. I split the application into 2 microservices: Account microservice for User aggregate and Insight microservice for JobTitle, Skill and Course aggregates. The problem with this solution is that it will create a cluster communications between Account and Insight since most of time Account need data from Insight microservice for it's business logics. And the original problem that Account microservice helds most of APIs for FE is not eliminated.
  2. Keeping 4 microservices Account, JobTitle, Skill And Course. And pushing User dependent Entities into other corresponding microservices. For example user_skills will go into Skill microservice. This solution looks better but it will break DDD aggregate principle and could bring more problems later

How should I split this monolothic application into microserices?

1
microservicesdomain-driven-design
If you already know these entities are within the bounded context of your application, why would they need to be moved to a separate "microservice"? It seems like you're designing tightly coupled services. - im_baby
as I mentioned, if I keep these dependent Entities inside of Account microservice, most of business logic will live inside of Account. The other microservices become dummy microservices. - Mai Hữu Lợi

1 Answers

0
votes

I don't know exactly how many dependent relations the user entity has with the other aggregates, but in this case you could replicate the relation data in your user microservice and keeping it updated using events.

For example. If you have a table called user_skills then you can place it in the users domain and when a skill changes in the skill microservice, it will write an event in some sort of message broker like kafka and user microservice will be listen to consume that event and update its user-skill table accordingly.