Organization Relationships

Why This Exists

This document explains how the Organization Domain relates to every major Algosure domain.

Other domains depend on Organization context. They must reference Organization data without duplicating Organization ownership.

Owner

The owner is the Chief Product Officer and Enterprise Architect.

The Organization Domain owns Organization identity, profile, capabilities, resources, preferences, intelligence graph, and memory boundary.

Business Value

Clear relationships prevent duplicated data ownership, improve cross-domain consistency, and support the Architecture Mirror Principle.

Relationship Diagram

flowchart TD
    Org[Organization]
    Identity[Identity]
    Compliance[Compliance]
    Opportunity[Opportunity]
    Proposal[Proposal]
    Contract[Contract]
    Supplier[Supplier]
    Marketplace[Marketplace]
    Funding[Funding]
    Learning[Learning]
    Intelligence[Intelligence]
    Notification[Notification]
    Analytics[Analytics]
    Billing[Billing]
    Admin[Administration]

    Org --> Identity
    Org --> Compliance
    Org --> Opportunity
    Org --> Proposal
    Org --> Contract
    Org --> Supplier
    Org --> Marketplace
    Org --> Funding
    Org --> Learning
    Org --> Intelligence
    Org --> Notification
    Org --> Analytics
    Org --> Billing
    Org --> Admin

Domain Relationship Map

Domain	Relationship to Organization	Organization-owned data	Referenced-only data
Identity	Links users and access to Organization context.	Organization user association.	Credentials, authentication factors, identity sessions.
Compliance	Uses organization facts for eligibility and evidence.	Directors, certifications, licences, profile facts.	Compliance decisions and check results.
Opportunity	Uses profile, preferences, capability, geography, and industry data for matching.	Organization preferences and capabilities.	Opportunity lifecycle and opportunity records.
Proposal	Uses Organization data as proposal evidence.	Profile, services, projects, references, certifications.	Proposal content, response workflow, submission status.
Contract	Uses Organization identity and delivery context.	Legal identity, contacts, resources.	Contract obligations and delivery execution.
Supplier	References Organization when the customer acts as supplier.	Organization profile and offerings.	Supplier network records outside the customer organization.
Marketplace	Uses services, products, and supplier-facing profile.	Services, products, capability evidence.	Marketplace listing workflow and external matching rules.
Funding	Uses financial profile and organization eligibility.	Organization financial profile and preferences.	Funding application status and provider decisions.
Learning	Uses users, roles, maturity, and capability gaps.	Organization users and capability context.	Learning content and course progress model.
Intelligence	Uses graph and memory for insight.	Organization Intelligence Graph and memory boundary.	Cross-organization intelligence models.
Notification	Uses contacts and user associations.	Contact and user association data.	Notification templates and delivery records.
Analytics	Consumes Organization events and read models.	Organization source facts and events.	Analytics aggregates and dashboards.
Billing	Uses Organization as billing subject.	Organization identity and billing contact references.	Invoices, plans, payments, ledger.
Administration	Governs support and operational administration.	Organization status and admin metadata where owned.	Admin actions, support workflows, internal notes.

Ownership Rule

Organization owns canonical customer business context. Other domains may:

• Reference OrganizationId.
• Consume Organization events.
• Maintain read models.
• Request changes through Organization APIs.

Other domains may not:

• Create duplicate Organization profile ownership.
• Mutate Organization-owned facts directly.
• Treat cached read models as canonical truth.

Cross-Domain Reference Pattern

References must use stable identifiers and business events.

sequenceDiagram
    participant Domain as Downstream Domain
    participant OrgAPI as Organization API
    participant Org as Organization Aggregate
    participant Events as Event Mesh

    Domain->>OrgAPI: Request Organization read model
    OrgAPI->>Org: Load Organization-owned state
    Org-->>OrgAPI: Return governed data
    OrgAPI-->>Domain: Read model
    Org->>Events: Publish OrganizationProfileUpdated
    Events-->>Domain: Update downstream projection