Splitting up Monoliths
Team Topologies introduces the concept of “Fracture Planes”:
A fracture plane is a natural seam in the software system that allows the system to be split easily into two or more parts. (Skelton and Pais 2019, chap. 6)
They offer up these examples:
- Business Domains (ala Domain Driven Design)
- Regulatory Compliance (e.g. PCI compliant systems vs other things)
- Change Cadence (i.e. separate subsystems that change at different rates)
- Team Location (i.e. get teams to be located in the same office)
- Risk (e.g. free tier customers with a higher risk profile vs enterprise customers)
- Performance Isolation (e.g. performance critical systems vs other systems)
- Technology (i.e. split when when the tooling ecosystem is different enough to cause cognitive load when switching)
- User Personas (e.g. admin vs regular vs experienced users)
Quotes
A joined-at-the-database monolith is composed of several applications or services, all coupled to the same database schema, making them difficult to change, test, and deploy separately. (Cagan and Jones 2021, chap. 6)
Cagan, Marty, and Chris Jones. 2021. Empowered: Ordinary People, Extraordinary Products. Silicon Valley Product Group. John Wiley & Sons.
Skelton, Matthew, and Manuel Pais. 2019. Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press LLC.