I've been on both sides of this debate. I've seen codebases from teams that want monorepos and macroservices that fit all of the falling criteria:
- The codebase had three primary responsibilities
- None of those functions overlapped in functionality and didn't share any significant code
- They were all written by different people with subtly different styles
- They used infrastructure code for talking to third party services in subtly different ways that made upgrading dependencies difficult
In theory, they were all within the same business domain, so the types that think one business domain equals one service clumped them together. This made little sense.
On the opposite side, I've seen microservices where all the little services depended on one another in complicated ways that made them all a brittle mess.
Finding the right solution to each problem is always the real challenge.
- The codebase had three primary responsibilities
- None of those functions overlapped in functionality and didn't share any significant code
- They were all written by different people with subtly different styles
- They used infrastructure code for talking to third party services in subtly different ways that made upgrading dependencies difficult
In theory, they were all within the same business domain, so the types that think one business domain equals one service clumped them together. This made little sense.
On the opposite side, I've seen microservices where all the little services depended on one another in complicated ways that made them all a brittle mess.
Finding the right solution to each problem is always the real challenge.