Package Topology
This section describes how packages are organized, related, and consumed across the Platform.
Where the Domain Model explains why responsibilities are separated, Package Topology explains how that separation is enforced in practice: which packages depend on which, where boundaries exist, and how change propagates through the system.
This view is derived from the real repository structure and dependency graph — not an abstract ideal.
Dependency Direction (Invariant)
The Platform enforces a one-way dependency flow:
Applications → Adapter Packages → Domain Packages
Reverse dependencies are not allowed.
This invariant is what prevents architectural drift over time.
Structural Topology
The diagram below shows the authoritative dependency topology between domains, packages, and applications.
How to Read This Diagram
Domains define behavior once and never depend on packages or apps
Adapter packages depend on exactly one domain and expose runtime-specific APIs
Applications consume adapters only
This keeps responsibility clear and prevents shared logic from leaking upward.
Change Radius Visualization
Topology is not just about structure — it’s about blast radius.
The diagram below shows how a change propagates depending on where it occurs.
Why This Matters
This topology intentionally constrains how risk spreads:
Domain changes are rare and deliberate because they affect many consumers
Adapter changes are faster and scoped to a runtime or framework
Application changes are isolated and safe to experiment with
This is how the Platform remains stable while products evolve quickly.
Ownership Boundaries
Each layer has a clear ownership model:
Domains → platform-level ownership, slower cadence
Adapters → domain-adjacent ownership, moderate cadence
Apps → product ownership, rapid iteration
Ownership clarity prevents “shared code” from becoming unowned code.