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] (http://shop.oreilly.com/product/0636920080237.do) ↩
2. [Domain Driven Design by Eric Evans] (http://dddcommunity.org/book/evans_2003/) ↩
- A good example of code reuse is logging functionality or a service that provides business functionality, for example a VAT calculator