Module Boundaries and Integration Rules¶
Purpose¶
Define the rules that keep OpenSESA maintainable as cross-domain complexity grows.
Boundary Rules¶
- domain modules own their routes/views/templates/tests
- shared behavior belongs in
coreor explicit shared services - avoid direct imports of peer module internals
- keep integration contracts explicit and testable
Preferred Integration Pattern¶
flowchart LR
A["Owning Module"] --> S["Shared Contract/Service"] --> B["Consuming Module"] Anti-Pattern¶
flowchart LR
A["Module A"] -. direct internal import .-> B["Module B private helper"] Review Checklist¶
- ownership preserved for changed behavior?
- integration contract explicit?
- impacted modules have tests?
- docs updated for boundary changes?
Failure Modes¶
| Symptom | Likely Cause | Fix |
|---|---|---|
| fragile cross-module regressions | hidden internal imports | refactor to shared contract |
| refactor blocks unrelated modules | implicit coupling | isolate boundaries and re-test |
| unclear ownership in PR review | mixed routes/templates across modules | restore module ownership boundaries |
Typical regression cause
Hidden cross-module imports are a frequent source of upgrade and refactor breakage.