Design for Pace of Change

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

Rationale

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.

Implications

  • 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] (http://shop.oreilly.com/product/0636920080237.do)
2. [Domain Driven Design by Eric Evans] (http://dddcommunity.org/book/evans_2003/)

Examples

  • A good example of code reuse is logging functionality or a service that provides business functionality, for example a VAT calculator

results matching ""

    No results matching ""