Overview

Functional decomposition of the system into Domains, Modules, Services, and Endpoints. The criteria for each level — what defines a Module versus a Service versus an Endpoint, the canonical naming rules, and the URL formula — are documented in Functional Decomposition. The top-level diagram below shows the present-day grouping; the per-Domain pages give the detail of what each Domain contains.

Domains

The Arda system today comprises five functional Domains. The Domain canonical names use kebab-case lowercase; the per-Domain pages below catalog the Modules in each Domain.

Domain canonical	Pages	Modules covered
system	Overview	User Account, Tenant, AgentFor, Invitation (in the accounts-component); Batch (embedded inside operations)
reference (folder: reference-data)	Overview	Item, Business Affiliate
resources	Overview	Kanban Cards (Facility and Station are embedded supporting Modules of Kanban)
procurement	Overview	Orders
shop-access	(see Modules below)	PDF Render (in-pod consumer only); Email (per-tenant transactional email)

Modules and Endpoints

The full per-Endpoint table — every Endpoint published today, with canonical URL, current URL, and collapse pattern — is the Endpoints at a glance appendix in the API Endpoint Catalog. The per-API operation listing in the catalog body shows the actual published routes.

Shop Access

shop-access does not have a dedicated index.md of its own — the per-Module pages link directly:

• PDF Render — In-pod printing capability consumed by Item and Kanban. No public REST surface today.
• Email — Per-tenant transactional email through Postmark. The Email Module is in flight on PR-#182; it ships with the canonical URL shape /v1/shop-access/email/... per Functional Decomposition. Three Endpoints: Configuration, Job, PostmarkEvents. See the API Endpoint Catalog for the operations exposed.

Authentication

Authentication is a cross-cutting concern rather than a functional Domain. See Authentication for the JWT, OAuth2, Cognito, and realm/permission infrastructure.

Frontend

Frontend patterns and conventions are documented in Frontend Patterns.

Everything is Observable

Modules depend on each other in one direction, and that direction is the architecture’s spine: a module may call the modules it depends on and must not call the ones that depend on it. Operations run along that direction. Notifications run against it.

An operation is invoked: a caller names a module and asks it to do something, so the caller knows the callee. A notification is announced: a module states that something happened, and the modules that care react without being called. The announcer does not know its listeners and does not wait for them. That is what keeps the dependency direction intact while still letting information travel back up it.

The consequence is the name. Any change a module considers meaningful is observable by any other module, without the announcer acquiring a dependency on the observer. A new consumer of an existing announcement costs the announcing module nothing — it does not change, and it does not learn that the consumer exists.

Two things follow that are easy to get wrong. A notification is not a request: nothing about it obliges a listener to act, and a module that needs an answer must call rather than announce. And a listener reacts to what the announcement carries, rather than calling back to ask what happened — a listener that re-reads the announcer has quietly reintroduced the dependency the notification exists to avoid.

In the sequence diagrams throughout these pages, a solid arrow is an operation and points along the dependency direction; a dashed arrow is a notification and points against it.

For how this is implemented — post-commit dispatch, transaction boundaries, and the traps around cascades — see Observer Patterns.

Related Pages

• Functional Decomposition — Criteria for each level of the hierarchy and the canonical naming rules.
• Module Concept — Module-level deep dive.
• Component Concept — How Modules are packaged into deployable Components.
• API Endpoint Catalog — Concrete URLs published today.
• Data Models — Reading guide for the per-module data-model pages: stored versus projected shape, and the record envelope they share.
• The Orders v2 Call Shape — The request/response convention nearly every call follows, and the one module that predates it.
• Legacy State — Divergences between the canonical naming and the live system’s URLs, plus the cardinality-transition and collapse-rule mechanics that govern Module evolution.