A bit of my situation is that we have broken down work into far too many projects. Making changes to the data model and how it functions requires that you update at minimum 3 dependency jars and 3 end applications to get the change used everywhere.
The direction that I recommend is that any unit of work that shares no functionality or dependency with any other block of work should be separated into a different microservice. If there is a common data model that needs to be shared between half of a dozen microservices then you are making it too difficult by being separated. Maybe they should become more monolithic so that the code only needs to be changed in one place. Maybe that monolith should be a mono-repo that builds multiple applications instead of having so many dependencies that need to be packaged.
Consider the difficulty involved in making changes to the deepest parts of the application if you needed to change a major approach to the data (maybe adopting a better ORM) or maybe using Springboot instead of the homespun framework setup that the original architect made and nobody knows how to make truly cloud native.
tl;dr: do what works BEST for you
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.
Very well explained.
A bit of my situation is that we have broken down work into far too many projects. Making changes to the data model and how it functions requires that you update at minimum 3 dependency jars and 3 end applications to get the change used everywhere.
The direction that I recommend is that any unit of work that shares no functionality or dependency with any other block of work should be separated into a different microservice. If there is a common data model that needs to be shared between half of a dozen microservices then you are making it too difficult by being separated. Maybe they should become more monolithic so that the code only needs to be changed in one place. Maybe that monolith should be a mono-repo that builds multiple applications instead of having so many dependencies that need to be packaged.
Consider the difficulty involved in making changes to the deepest parts of the application if you needed to change a major approach to the data (maybe adopting a better ORM) or maybe using Springboot instead of the homespun framework setup that the original architect made and nobody knows how to make truly cloud native.
tl;dr: do what works BEST for you