The system boundary#
A Matrix Consumer is a business application that composes Matrix packages. The resulting user experience is its Product. The Consumer owns its domain model, rules, persistence, application authorization and integration adapters. Matrix contributes the kernel, hosting and selected feature modules.
Portal, Workflow and Messages are independent first-party services. They can use Matrix packages themselves without becoming modules inside every Consumer. Infrastructure supplies the shared operational foundation. Package references and network integrations describe different dependencies.
Component responsibilities#
| Boundary | Owns | Does not transfer to it |
|---|---|---|
| Consumer API and Web | Domain rules, typed adapters, presentation composition, business writes and application policy | Domain authority does not move to Portal or a message broker |
| Matrix kernel and Shell | Stable module/resource/action/target identifiers, catalog composition, hosting and neutral integration seams | A common application database or universal business model |
| Optional modules | Feature contracts and their selected API, provider and UI implementations | A requirement to install every feature |
| Portal | Application launch directory and documented shared preferences/session contracts | Authorization inside a launched application |
| Workflow | Definition versions, instances, orchestration, human task decisions and process progress | Participant domain transactions |
| Messages | Acceptance, delivery projections, inbox state and registered action navigation | Underlying task completion or business authorization |
| Infrastructure | Identity provider, ingress, service allocations, runtime configuration and operational lifecycle | Application schema migrations or business policy without an approved application contract |
Code dependencies point inward#
The provider-neutral Domain and Application packages form the kernel. Shell packages depend on that kernel. Feature modules own their contracts and optional providers, API endpoints and UI implementations; the generic Shell does not depend on a particular feature module.
The Consumer composes matching API and Web capabilities. Generated CRUD is explicitly installed. A custom page can use normal Razor UI and a typed Consumer API without requiring CRUD or Entity Framework. Reporting, dashboards, wizards and preferences have their own ownership and execution contracts.
Use Core architecture for the dependency rules and module composition for host registration and constrained configuration.
Network contracts keep state ownership separate#
An application can use Portal launch and SSO while remaining responsible for its own session and endpoint policy. A launch link is a destination, not a transported access token. Shared identity does not make every application operation authorized.
Workflow directs service work through typed operations. A participant executes its own business transaction and retains the outcome under its durable operation contract. RabbitMQ is transport. An acknowledgement from transport does not establish that the intended business effect committed.
Messages projects information and tasks into a common inbox. Opening or marking an item read changes presentation state. An application must still authorize the destination action, commit its own mutation and provide the required receipt before the process can advance.
This distinction enables both orchestration and event-driven choreography. Workflow owns progress in a directed process. Independent subscribers react to committed business events under their own contracts. Neither path creates a global database transaction across all services.
Authorization is enforced at the owning boundary#
Matrix resource/action decisions help compose an authorized catalog and protect corresponding operations. Consumers still implement tenant, record and field restrictions where their domain requires them. A hidden navigation item is not a security boundary.
Workflow task eligibility, Messages recipient visibility and a destination application's current authorization are related checks, not interchangeable checks. Re-evaluate authority when executing an operation; a previously visible message or cached menu does not grant continuing permission.
Audit events also require an explicit durable integration. A default diagnostic sink or correlation identifier is not retained business evidence. Select storage, access, retention, failure behavior and recovery verification for the target release and environment.
From design to an accepted installation#
Choose the smallest component set that meets the requirement. Record package versions, typed schemas, operations, identity audiences and data owners. Verify the composed application locally, then qualify its published artifacts and deployment separately.
The deployment guide distinguishes local Aspire execution from installed Docker services. The operations guide covers the evidence needed for restore, lifecycle maintenance and ongoing support.