harsh817 Module And Boundary Design
Definition
Place feature knowledge in the modules best able to hide it. Boundaries should reduce cognitive load, avoid information leakage, and keep layers at distinct abstraction levels.
Questions To Ask
- Which module owns this feature's domain rule?
- Which layer should know about UI state, API transport, persistence, and business policy?
- What must cross the boundary, and what must stay hidden?
- Are any new modules shallow wrappers?
- Does the feature require moving complexity downward?
Existing Project Comparison
- Inspect existing modules, folders, imports, commands, services, and tests.
- Compare proposed boundaries with
AGENT_GUARDRAILS.md. - Identify duplicated rules, pass-through layers, and ownership conflicts.
Suggestive Plan
- Identify owner module.
- List affected modules and responsibilities.
- Define allowed dependency direction.
- Mark hidden decisions per module.
- Remove pass-through or shallow boundaries.
Example
Scheduling owns appointment-window rules. API routes translate requests. UI manages form state. Data access persists scheduling state without owning scheduling policy.
Vocabulary
- Boundary: line where modules or layers communicate.
- Owner module: module responsible for rules and decisions.
- Information hiding: keeping design knowledge inside the owner.
- Pass-through layer: layer that forwards without adding abstraction.
Expected Outcome
Produce a boundary map with owner modules, responsibilities, hidden details, allowed dependencies, and boundary risks.