Strategic Design

CrowdVision is modelled with a Domain-Driven Design (DDD) mindset. We approached the system not as one monolithic model but as a set of collaborating models, each owned by a context and each speaking its own dialect of a shared Ubiquitous Language. This page captures the strategic design decisions taken up front — the subdomains, the bounded contexts, and the relationships between them. The tactical model (aggregates, entities, value objects, domain services) is described per context on the following pages. The user stories that seeded these decisions — and the places where backlog and design deliberately part ways — are catalogued in User Stories.

Domain and Subdomains

The overall domain is real-time monitoring of physical spaces through a digital twin. We classify the subdomains by how much competitive value they carry, which in turn drives how much modelling effort each is given.

Bounded Contexts

A guiding decision is that each core and supporting subdomain becomes exactly one bounded context, and each context is meant to stand on its own — its own model, its own storage, its own boundary. We chose this alignment so that a model can never quietly leak into another context through shared data: a context boundary is also intended to be a deployment and storage boundary.

graph TB
    subgraph IA["Identity and Access Context"]
        ACC["Account / Domain"]
    end
    subgraph BM["Building Management Context"]
        BLD["Building / Room"]
    end
    subgraph TI["Telemetry Ingestion Context"]
        SIG["Signals / Thresholds"]
    end
    subgraph TD["Telemetry Distribution Context"]
        PRF["Building Preferences"]
    end
    subgraph AL["Alerting Context"]
        SUB["Delivery / Preferences"]
    end
    subgraph KA["Knowledge and Assistance Context"]
        DOC["Inquiries / Knowledge Sources"]
    end

    IA -.->|"identity claims"| BM
    IA -.->|"identity claims"| AL
    IA -.->|"identity claims"| KA
    BM -->|"structural metrics"| TD
    BM -->|"threshold baseline"| TI
    BM -->|"domain resolution"| AL
    TI -->|"readings"| TD
    TI -->|"metric catalog"| TD
    BM -->|"live building data"| KA
    TI -->|"live signals and thresholds"| KA

The Real-Time Transport context is omitted from the map: it is meant to carry messages between contexts but to hold no model and enforce no rules.

Context Map

We describe the relationships between contexts with the standard DDD integration patterns. They tell a contributor who depends on whom and which side dictates the contract. The interactions are stated conceptually; concrete endpoints belong to the implementation.

Model Integrity Patterns

The Context Map above is organised by relationship pair. Here we restate the same decisions organised by pattern, so it is explicit which of the model-integrity patterns we relied on and where. We use all four.

Two further integration patterns appear in the Context Map and are worth naming: the identity token and the metric descriptions are both Published Language, and Telemetry Ingestion exposes its metrics as an Open Host Service so new metrics surface downstream without a coordinated change. We did not need a Separate Ways or Partnership relationship — no two contexts are either fully independent or jointly owned.

The Shared Identifier Convention

Across the platform, we decided that a Domain is referenced by its name, never by an internal database identifier. This is the closest thing the design has to a Shared Kernel, and it is deliberately minimal: a single, stable, human-readable string rather than shared code.

erDiagram
    ACCOUNT ||--o{ MEMBERSHIP : holds
    MEMBERSHIP }o--|| DOMAIN_NAME : "references by name"
    BUILDING }o--o{ DOMAIN_NAME : "scoped by name"
    PREFERENCE }o--|| DOMAIN_NAME : "scoped by name"

Because the domain name travels inside the identity token and is recorded by each context, the intent is that multi-tenant isolation can be enforced symmetrically — each context answers “may this caller see this data?” from data it already holds, without consulting another context.

Tactical Building Blocks

We build the tactical model from the seven DDD building blocks. The table states, for each, whether we reached for it, and where it sits in our model — at the model level, deliberately ahead of any implementation. The blocks recur throughout the per-context pages.

On the per-context pages these blocks do not get headings of their own. Because an entity or a value object has no meaning outside the aggregate that owns it, each is documented inside its aggregate — tagged with its <<Entity>> / <<Value Object>> stereotype in the aggregate’s class diagram, and explained alongside the aggregate root. The aggregate is the unit of presentation, exactly as it is the unit of consistency.