Lab 1.5: Connecting the Dots
Module: 1.5 - Dependency Mapping | ← SlidesDuration: 1 hour Sample Project: node-express-mongoose-demo
Learning Objectives
By the end of this lab, you will be able to:
- Identify downstream dependencies (what depends on this?)
- Identify upstream dependencies (what does this depend on?)
- Assess the blast radius of potential changes
- Make informed decisions about refactoring risk
Prerequisites
- Completed Lab 1.2 and 1.3
- Sample project ready with CLAUDE.md
- Understanding of the project's basic structure
Setup
# Navigate to the sample project
cd sample-projects/node-express-mongoose-demo
# Start Claude Code
claudeTask 1: Identify a Core Module
Time: 5-8 minutes
Find a module that is central to the application.
Prompts to try:
What are the most important or frequently used modules in this codebase?Which modules are imported by the most files?Expected Outcome
You've identified a module worth analyzing (e.g., a model, a service, or a middleware).
Success criteria:
- [ ] Identified at least one core module
- [ ] Understand why it's considered "core"
Task 2: Map Downstream Dependencies
Time: 15-20 minutes
Find everything that depends on your chosen module.
Prompts to try:
What components depend on the User model?List all files that import or use the article controller.Where is the auth middleware used?Follow-up prompts:
Can you categorize these dependencies by type (controllers, routes, tests)?Expected Outcome
A complete list of code that would be affected by changes.
Success criteria:
- [ ] Listed all files/modules that depend on the target
- [ ] Categorized dependencies (if applicable)
- [ ] Understand the blast radius
Task 3: Map Upstream Dependencies
Time: 15-20 minutes
Find what your chosen module depends on.
Prompts to try:
What external libraries does the User model use?What other modules does the article controller import?What configuration does this module depend on?Expected Outcome
A list of all external risks (libraries, APIs, other modules).
Success criteria:
- [ ] Listed all imports and dependencies
- [ ] Identified external libraries used
- [ ] Understand what could break this module from outside
Task 4: Assess the Blast Radius
Time: 15-20 minutes
Synthesize your findings into a risk assessment.
Prompts to try:
If I needed to refactor the User model, what would be the safest approach?What would break if I changed the authentication middleware's API?Create a Mermaid diagram showing the dependencies of the article module.Document your findings:
- Is the blast radius small, medium, or large?
- What's the risk level for refactoring?
- What should be tested before any changes?
Success criteria:
- [ ] Written assessment of blast radius
- [ ] Risk level identified (low/medium/high)
- [ ] Recommendations for safe changes
Interpreting Results
| Blast Radius | Characteristics | Recommendation |
|---|---|---|
| Small | Few dependencies, well-isolated, mostly used by tests | Safe to refactor |
| Medium | Several dependencies, used by multiple components | Test thoroughly |
| Large | Many dependencies, core to application, high coupling | Plan carefully |
Tips for Success
- Start with critical systems - Auth, data models, core services
- Look for surprises - Unexpected dependencies = hidden coupling
- Ask "why" questions - "Why does X depend on Y?"
- Generate diagrams - Visual representations help understanding
Troubleshooting
Too many dependencies
- Focus on the most important ones first
- Ask Claude to prioritize by usage frequency
Circular dependencies found
- Document these carefully
- They indicate architectural issues
Stretch Goals
If you finish early:
- Generate a Mermaid dependency diagram
- Identify "God modules" (modules everything depends on)
- Find orphaned code (modules nothing depends on)
Deliverables
At the end of this lab, you should have:
- A dependency map for at least one core module
- Risk assessment (blast radius analysis)
- Recommendations for safe refactoring
Next Steps
After completing this lab, move on to Lab 1.6: The Scribe.