Skip to content

Module Boundaries and Integration Rules

Purpose

Define the rules that keep OpenSESA maintainable as cross-domain complexity grows.

Boundary Rules

  1. domain modules own their routes/views/templates/tests
  2. shared behavior belongs in core or explicit shared services
  3. avoid direct imports of peer module internals
  4. 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.