design-deep-moduleslisted

# Design Deep Modules ## Objective Improve a cohesive boundary so callers rely on a small, stable contract while the module owns meaningful functionality, policy, coordination, validation, dependency handling, and change-prone decisions. Apply the lens within the primary task rather than redefining it. Treat review as input to a boundary decision, not as a search for more abstractions. Recommend the smallest durable change supported by evidence. ## Depth Standard Optimize for depth, not size. Judge the interface by the total knowledge required to use it correctly, including: - operations, types, events, options, and configuration - preconditions, side effects, failure semantics, and consistency guarantees - ordering, lifecycle, ownership, cleanup, and compatibility expectations - internal concepts or call sequences callers must reconstruct Judge the implementation by the useful, cohesive knowledge it hides. Count domain rules, workflows, algorithms, state transitions, integration differences, validation, authorization, retries, transactions, caching, observability, and recovery behavior as depth when they belong to the same abstraction. Require both depth and cohesion. Do not treat a small interface as justification for a god module, or a large file as proof that a boundary should be split. Do not confuse a deep module with a deployment topology. Apply the lens within a process, package, library, plugin, or service boundary without using it alone to justify distribu