Dependency Governance
Systematically manage dependencies to reduce coupling, track vulnerabilities, and maintain security.
Context
You are governing dependencies in the system. Reduce external library reliance, manage service dependencies, deprecate old systems. Read dependency graphs, vulnerability reports, deployment constraints.
Domain Context
Based on dependency management and architectural modularity:
- Library Dependencies: Third-party code you compile into application. Vulnerability risk, maintenance burden, version conflicts.
- Service Dependencies: Other services your system calls (REST, gRPC, message queues). Coupling, availability risk, latency impact.
- Data Dependencies: Databases, caches, data lakes shared between systems. Schema coupling, migration complexity.
- Transitive Dependencies: Dependencies of your dependencies. Hard to track, security risk. Dependency hell.
Instructions
Map Dependency Graph: What does your system depend on? List direct dependencies (libraries, services, databases). Then transitive (dependencies of dependencies).
Audit for Risk: Libraries: any known vulnerabilities? Check with OWASP, CVE databases. Services: what's the SLA? What happens if it fails? Data: can you evolve schema independently?
Reduce Coupling: Remove unused libraries. Extract service dependencies into adapters (easier to swap). Copy small utilities instead of depending on library. Use event-driven instead of direct service calls.
Version Management: Update regularly; don't skip versions (harder to jump 5 versions than 1). Automate dependency updates (dependabot, renovate). Test each update in CI before merging.
Plan Deprecation: For dependencies you want to remove, announce timeline. Give teams 6-12 months to migrate. Finally remove or mark as deprecated. Track adoption.
Anti-Patterns
- Transitive Dependency Hell: 100 libraries installed, only use 5. Result: bloated, security risk, slow builds. Guard: Audit transitive deps; remove heavy frameworks for simple use cases.
- Version Pinning Forever: Pin to old version to avoid updates. Result: security vulnerabilities, incompatibility with new tools. Guard: Regular updates; automate testing.
- Service Coupling Without Fallback: Service A calls Service B without retry logic. Result: cascading failure. Guard: Circuit breaker, fallback, timeout; design for fault tolerance.
- No Deprecation Path: Remove dependency without warning. Result: broken builds. Guard: Announce 6+ months early; provide migration guide; track adoption.
Further Reading
- Working with Legacy Code by Michael Feathers — managing large dependency bases
- Release It! by Michael Nygard — designing for service dependency failures
- Scaling Microservices by Sam Newman — dependency patterns in distributed systems
1---2name: dependency-governance3description: Manage and optimize system dependencies (libraries, services, data). Reduce coupling, track vulnerabilities, plan deprecation. Use when managing dependency sprawl or improving system modularity.4---56# Dependency Governance78Systematically manage dependencies to reduce coupling, track vulnerabilities, and maintain security.910## Context1112You are governing dependencies in the system. Reduce external library reliance, manage service dependencies, deprecate old systems. Read dependency graphs, vulnerability reports, deployment constraints.1314## Domain Context1516Based on dependency management and architectural modularity:1718- **Library Dependencies**: Third-party code you compile into application. Vulnerability risk, maintenance burden, version conflicts.19- **Service Dependencies**: Other services your system calls (REST, gRPC, message queues). Coupling, availability risk, latency impact.20- **Data Dependencies**: Databases, caches, data lakes shared between systems. Schema coupling, migration complexity.21- **Transitive Dependencies**: Dependencies of your dependencies. Hard to track, security risk. Dependency hell.2223## Instructions24251. **Map Dependency Graph**: What does your system depend on? List direct dependencies (libraries, services, databases). Then transitive (dependencies of dependencies).26272. **Audit for Risk**: Libraries: any known vulnerabilities? Check with OWASP, CVE databases. Services: what's the SLA? What happens if it fails? Data: can you evolve schema independently?28293. **Reduce Coupling**: Remove unused libraries. Extract service dependencies into adapters (easier to swap). Copy small utilities instead of depending on library. Use event-driven instead of direct service calls.30314. **Version Management**: Update regularly; don't skip versions (harder to jump 5 versions than 1). Automate dependency updates (dependabot, renovate). Test each update in CI before merging.32335. **Plan Deprecation**: For dependencies you want to remove, announce timeline. Give teams 6-12 months to migrate. Finally remove or mark as deprecated. Track adoption.3435## Anti-Patterns3637- **Transitive Dependency Hell**: 100 libraries installed, only use 5. Result: bloated, security risk, slow builds. **Guard**: Audit transitive deps; remove heavy frameworks for simple use cases.38- **Version Pinning Forever**: Pin to old version to avoid updates. Result: security vulnerabilities, incompatibility with new tools. **Guard**: Regular updates; automate testing.39- **Service Coupling Without Fallback**: Service A calls Service B without retry logic. Result: cascading failure. **Guard**: Circuit breaker, fallback, timeout; design for fault tolerance.40- **No Deprecation Path**: Remove dependency without warning. Result: broken builds. **Guard**: Announce 6+ months early; provide migration guide; track adoption.4142## Further Reading4344- _Working with Legacy Code_ by Michael Feathers — managing large dependency bases45- _Release It!_ by Michael Nygard — designing for service dependency failures46- _Scaling Microservices_ by Sam Newman — dependency patterns in distributed systems
sethdford