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/) ↩
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?