Module Dependency Rules

Executive Summary

Module Dependency Rules define how modules may depend on each other without violating ownership.

Dependency Flow

flowchart LR
    API[API Boundary]
    App[Application Service]
    Domain[Domain Model]
    Repo[Private Repository]
    Event[Domain Event]
    Other[Other Module Handler]

    API --> App
    App --> Domain
    App --> Repo
    Domain --> Event
    Event --> Other

Allowed Dependencies

Dependency	Allowed When
Shared kernel	Only for approved primitives and metadata.
Application service	When an approved synchronous use case requires another module's owned behavior.
API contract	For explicit command or query boundaries that do not expose internals.
Internal event	Preferred for asynchronous workflow coordination.
Projection	When a read model is explicitly governed and tenant-scoped.

Forbidden Dependencies

Dependency	Reason
Other module repository	Violates data ownership.
Other module aggregate/entity	Leaks internal model.
Other module database table	Violates source fact ownership and tenant isolation.
Generic shared business service	Creates shared dumping ground.
Generic orchestration god module	Breaks Domain and Practice ownership.
AIOS direct database access	Bypasses application service and audit boundaries.

Dependency Review Checklist

• Does the dependency preserve source Domain ownership?
• Can an event replace a synchronous dependency?
• Is tenant and organization context preserved?
• Is the dependency covered by Spring Modulith boundary tests?
• Would the dependency block future microservice extraction?