Dependency Adoption
Making use of software libraries or services as a dependency.
Also Known As
- Library Integration
- Open-Source Consumption
- Runtime Adoption
- Runtime Dependency
- Standards Adoption
Related
Addresses / Mitigates
- Implementation Risk: Ensures consistency and reliability by adhering to proven standards and libraries.
- Implementation Risk: Reduces the risk of relying on proprietary or less widely adopted solutions.
- Complexity Risk: Can reduce the amount of code you are responsible for, hence the amount of 'owned' complexity.
Attendant Risks
- Feature Fit Risk: Creates dependencies on the adopted standards and libraries.
- Lock-In Risk: Adopting proprietary libraries may lead to worsening terms-of-service in the future.
- Funding Risk: Can incur costs associated with adopting standards or libraries.
Description
"In software engineering, a software library is a collection of code that can be reused across different programs to provide commonly needed functionality." - Library, Wikipedia
Making use of third-party libraries or services in your code can dramatically reduce development time and leverage battle-tested solutions.
Variations
| Dependency Type | Description | Reference |
|---|---|---|
| Software Library | Reusable code packages that provide specific functionality (e.g., React, Lodash). | Library, Wikipedia |
| Framework | A larger structure that provides scaffolding and dictates application architecture. | Software Framework, Wikipedia |
| Software-as-a-Service | External services accessed via APIs (e.g., Stripe, AWS). | Software as a Service, Wikipedia |
See also: Languages and Dependencies, Software Libraries, Software-as-a-Service
Used By
No methods use this practice