Organization Aggregates

Why This Exists

This document defines the aggregate model for the Organization Domain.

Domain-Driven Design uses aggregates to protect business invariants and define transaction boundaries. The Organization aggregate is the root aggregate for customer business context in Algosure.

Owner

The owner is the Chief Product Officer and Enterprise Architect.

Aggregate ownership is governed by the Organization Domain. Other domains reference aggregate IDs; they do not own Organization aggregate state.

Business Value

Aggregate boundaries preserve consistency in customer identity, profile, capabilities, resources, experience, preferences, intelligence, and memory. They prevent other domains from mutating Organization-owned data without governance.

Organization Aggregate Root

The Organization aggregate root represents the customer business entity.

It owns:

• Organization identity.
• Lifecycle state.
• Core profile references.
• Ownership and user association rules.
• High-level status and governance metadata.
• References to supporting Organization aggregates.

Supporting Aggregates

Aggregate	Purpose	Boundary
Organization Profile	Legal, trading, descriptive, contact, branch, department, and structural profile.	Changes to organization profile data.
Capability Profile	Services, products, capabilities, certifications, licences, and evidence.	Changes to what the organization can offer or prove.
Resource Profile	Equipment, fleet assets, employees, and operational resources.	Changes to operating capacity and delivery assets.
Experience Profile	Past projects and client references.	Changes to experience evidence.
Procurement Preference Profile	Target sectors, regions, opportunity preferences, exclusions, and constraints.	Changes to opportunity matching preferences.
Organization Intelligence Graph	Connected facts, semantic relationships, inferred insights, and memory links.	Changes to connected organization intelligence.

Aggregate Diagram

flowchart TD
    Org[Organization Aggregate Root]
    Profile[Organization Profile Aggregate]
    Capability[Capability Profile Aggregate]
    Resource[Resource Profile Aggregate]
    Experience[Experience Profile Aggregate]
    Preferences[Procurement Preference Profile Aggregate]
    Graph[Organization Intelligence Graph Aggregate]

    Org --> Profile
    Org --> Capability
    Org --> Resource
    Org --> Experience
    Org --> Preferences
    Org --> Graph

Aggregate Boundaries

Aggregate boundaries follow business consistency needs.

The Organization aggregate root protects identity and lifecycle invariants. Supporting aggregates protect specialized consistency areas and may evolve independently when transaction boundaries require it.

Core Invariants

Invariant	Description
Organization identity is stable	An OrganizationId must not change after creation.
One root per customer business entity	Duplicate active Organization roots for the same legal entity require governance review.
Status transitions are controlled	Organization lifecycle changes must follow lifecycle rules.
Profile ownership is centralized	Other domains must not own canonical Organization profile facts.
AI-enriched facts require provenance	AI-suggested organization facts must be marked and reviewable.

Transaction Boundaries

Transactions should remain inside a single aggregate when possible.

Examples:

• Updating organization legal name: Organization Profile aggregate.
• Adding a service: Capability Profile aggregate.
• Registering equipment: Resource Profile aggregate.
• Adding a past project: Experience Profile aggregate.
• Changing opportunity preferences: Procurement Preference Profile aggregate.

Cross-aggregate changes should publish domain events instead of requiring a distributed transaction by default.

Referencing From Other Domains

Other domains reference:

• OrganizationId
• Supporting aggregate IDs where required.
• Published read models.
• Domain events.

They must not duplicate Organization-owned state as their source of truth.