When a project grows successfully, with time amount of code grows, and more devs are hired. This often leads to:

• a bloated codebase — harder for new engineers to understand, slower to change
• tight coupling between many modules — releases require more coordination and happen less frequently
• growing coordination overhead — N team members can form up to N² communication paths
• legacy accumulation — dependencies receive updates, but codebase upgrades are postponed due to fear of breaking changes
• longer build times
• increasing hardware requirements for all environments

This is a time when teams start thinking about splitting the system into smaller, independently evolving parts.

Would you name the approach? :)