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 it's 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] (

Points for discussion

  • If there are lots of different components do you take into account the pace of change of the components?
  • Do you over-engineer your solutions?
  • Do you reuse for the sake of it?
  • Is your system going to be around for a long time?

results matching ""

    No results matching ""