Cost of change is the time and resources needed to modify a product or system. In software, it rises when code is hard to learn, understand, change, test, or deploy. It is not solely a property of the code: code quality and team skill also matter. section 9.3.2
Use cost of change alongside rate of change when deciding subdomain boundaries. Separating code that rarely changes can make frequently changed code cheaper to evolve. But an expensive boundary is less pressing if changes seldom cross it. Past change rates offer evidence, not certainty about future demand. section 9.3.2
Balancing delivery and platform health
At mobile.de, engineers and product managers took on a new global platform while a smaller team still maintained a complex existing platform and pursued product goals. The delivery-first approach proved unsustainable after one quarter. Cost of change gave stakeholders a shared way to discuss continued investment in platform health and technical debt. section 16.3.5
High cost of change does not automatically make a subdomain strategically important. Avoidable complexity can make a supporting subdomain expensive to maintain. If it must keep evolving, reducing that complexity can enable new features; if little change is expected, extensive modernization may not repay the investment. Where subdomains are tightly coupled, teams may need a coordinated strategy rather than separate plans. section 10.3.7
