Software Architecture: The Hard Parts — Episode 2

The second session focuses on choosing how to decompose a monolith. If components can be identified, the team cleans them up before extraction. Otherwise tactical forking copies the application for two teams and each removes the other domain. This starts quickly but duplicates technical debt.

The current structure is assessed through abstractness, instability, and distance from the main sequence. Instability uses fan-in and fan-out. A concrete stable module enters the zone of pain, while an unused abstract module sits in the zone of uselessness. The hosts question the modern value of counting interfaces.

Component-based decomposition starts by finding and measuring components. Oversized areas are split, repeated domain concerns are consolidated, and namespaces are flattened. Fitness functions flag unexpected components, size outliers, and forbidden dependencies. They are governance signals, not unconditional bans.

Components are grouped into domains before deciding whether each needs a runtime; a service-based monolith with one database may suffice. Shared logic can become a library or service, but a service adds networks, latency, and failures. Boundaries should follow bounded contexts and transactions: splitting before the business model is clear creates a distributed monolith.