Dependency Mapping

Before you write a single line of module code, draw the dependency map. What does this module depend on? External APIs, databases, other modules, configuration values, environment variables. Every dependency is a potential failure point. Every failure point needs a plan. The dependency map is not documentation — it is the risk surface of your module, drawn out so you can see it before it surprises you in production.

There is a rule I apply to every architecture: if a module has more than three external dependencies, the architecture needs to be rethought, not extended. This is the 3-layer rule applied to dependency management. A module that depends on two APIs, a database, a file system, and three other modules is not a module — it is a system wearing a module costume. Break it apart. Each dependency cluster becomes its own module with its own contract. The parent module orchestrates the children. Now each piece can fail independently, be tested independently, and be replaced independently.