Domain Relationships¶
Why This Exists¶
This document explains how Algosure domains relate to each other without violating ownership boundaries.
Owner¶
The owner is the Chief Product Officer and Enterprise Architect.
Business Value¶
Relationship clarity enables modular implementation, reliable AI reasoning, safe workflow orchestration, and maintainable platform evolution.
Relationship Types¶
| Relationship type | Description | Example |
|---|---|---|
| Reference | One domain stores another domain's identifier. | Bid references OpportunityId. |
| Event Subscription | One domain reacts to another domain's event. | Notification reacts to BidApprovalRequired. |
| Command Request | One domain asks another domain to perform an owned action. | Administration requests Identity policy enforcement check. |
| Derived View | One domain builds a read model from source facts. | Analytics builds compliance trend snapshots. |
| Reasoning Support | Intelligence analyzes or explains source context. | Intelligence explains a bid/no-bid recommendation. |
| Entitlement Signal | Billing sends access state used by Identity or Platform. | Identity uses Billing entitlement signal. |
High-Level Relationships¶
flowchart TD
Organization[Organization Root Context]
Identity[Identity Access]
Billing[Billing Entitlements]
Administration[Administration Governance]
Intelligence[Intelligence Reasoning]
Compliance[Compliance Readiness]
Opportunity[Opportunity Discovery]
Bid[Bid Execution]
Contract[Contract Delivery]
Supplier[Supplier Trust]
Marketplace[Marketplace Discovery]
Funding[Funding Support]
Learning[Learning Capability]
Notification[Notification Delivery]
Analytics[Analytics Insight]
Organization --> Compliance
Organization --> Opportunity
Organization --> Bid
Organization --> Contract
Organization --> Supplier
Organization --> Funding
Organization --> Learning
Identity --> Organization
Billing --> Identity
Administration --> Identity
Compliance --> Opportunity
Opportunity --> Bid
Bid --> Contract
Contract --> Supplier
Supplier --> Marketplace
Marketplace --> Supplier
Contract --> Funding
Compliance --> Learning
Opportunity --> Learning
Bid --> Learning
Contract --> Learning
Intelligence --> Compliance
Intelligence --> Opportunity
Intelligence --> Bid
Intelligence --> Contract
Notification --> Analytics
Compliance --> Analytics
Opportunity --> Analytics
Bid --> Analytics
Contract --> Analytics
Supplier --> Analytics
Funding --> Analytics
Learning --> Analytics
Cross-Domain Reference Rules¶
- Reference by ID, not copied ownership.
- Store source domain and aggregate type where ambiguity is possible.
- Include event IDs or correlation IDs when a reference is event-derived.
- Do not use another domain's database tables as an integration API.
- Do not assume a referenced record is current without refresh or event handling.
Workflow Relationship Examples¶
Opportunity To Bid¶
Opportunity owns tender discovery, matching, and recommendation state. Bid begins when an organization chooses to pursue an opportunity. Bid references the Opportunity but owns the bid workspace and all bid preparation work.
Bid To Contract¶
Bid owns submission and outcome capture. Contract begins after award or contract creation. Contract owns delivery state, milestones, invoices, payments, risks, and closeout.
Billing To Identity¶
Billing owns entitlement facts. Identity enforces access decisions using entitlement signals along with user, role, permission, tenant, session, and policy context.
Source Domains To Analytics¶
Analytics consumes source events and creates snapshots, dashboards, and insights. Analytics does not mutate source facts.
Source Domains To Notification¶
Source domains request notifications. Notification owns delivery state and communication history.
Spring Boot Modulith Alignment¶
Domain relationships should become explicit module dependencies, events, and published application services. Modulith tests should verify that domains do not reach into each other's internals.