Design for Pace of Change

For components that change often, favour designing for pace of change over re-use


For systems that change often, designing for re-use can inhibit rapid change by creating dependencies and bottlenecks. If a system changes less frequently its maintenance cost becomes more important and designing for reuse can help reduce this.

Code that is designed for re-use is generally harder to use and more expensive to create than code designed for a single purpose1.


  • Focus on re-use as it emerges through evolution.
  • Be sceptical of components that look similar but aren't the same
  • Domain-specific component sharing is an anti-pattern; code re-use between bounded contexts is a hazard to be avoided2.
  • Systems should expose common business functions through APIs.
  • If re-used code becomes a bottleneck, remove the coupling by forking or duplicating the code1.
  • Features such as monitoring, logging, service discovery, authentication/authorisation often need to be implemented consistently across all services/applications. Use Service Templates to define which libraries should be used by all services1.
  • Shared components require robust tests, sufficient documentation and ongoing maintenance; a website to host generated docs may be useful.
1. [Building Evolutionary Architectures: Support Constant Change by Neal Ford, Patrick Kua, and Rebecca Parsons] (
2. [Domain Driven Design by Eric Evans] (

results matching ""

    No results matching ""