Reuse
Reuse, Adopt, Build
Summary
Engineers evaluate existing solutions before development begins, preferring internal reuse over external adoption and building a custom solution only when neither meets the requirement.
Reasoning
Starting development without checking existing options can duplicate capability and waste effort. Evaluating those options during design avoids committing to a new implementation that users and other systems may come to depend on.
Reusing an internal solution avoids creating another implementation to support. When no internal solution meets the requirement, an external solution can avoid the ongoing cost of custom development. Familiarity with a technology or the convenience of building something new does not justify rejecting a suitable existing option.
Implemented By These Standards
- Event-Driven Messaging
- Health Data Interoperability
- Runtime Architecture
- Service & Domain Design
- Code Style & Formatting
- Data Access & Transaction Management
- Linting & Style Enforcement
- Static Code Analysis
- Continuous Delivery & Deployment
- Continuous Integration
- Telemetry Instrumentation
- Infrastructure as Code
- Serverless
- Test Automation
Reusable Interfaces
Summary
Reusable components, services, and libraries have stable, documented, and versioned interfaces so other teams can use them without understanding their implementation.
Reasoning
A documented interface tells consumers what behaviour they can rely on without understanding the implementation. It keeps them from depending on internal design choices and gives every consumer the same contract.
Stable, versioned interfaces let providers improve an implementation without unexpectedly breaking consumers. Versioning gives consumers a clear migration path when the contract changes. Without a stable contract, teams have to coordinate changes that they should be able to make independently.