Skip to content

bounded-context-map.md

Latest commit

 

History

History
218 lines (171 loc) · 11 KB

bounded-context-map.md

File metadata and controls

218 lines (171 loc) · 11 KB

Evolith Tracker — Bounded Context Map (Official)

Bilingual Navigation: English (this document) · Versión en Español

Document Status: Draft Type: Strategic DDD — Context Map Satellite: Evolith Tracker Upstream: Evolith Core Date: 2026-06-07 Author: Architect Agent (BMAD) Resolves: Portal DDD closure — strategic context map (PROMPT MAESTRO §12 diagram #4)

1. Purpose

This is the single, authoritative strategic map of Evolith Tracker's 9 bounded contexts. Where each ddd-model.md documents the tactical design inside one context, this document defines the strategic relationships between contexts: their integration patterns (Customer-Supplier, Conformist, Anti-Corruption Layer, Shared Kernel, Partnership) and the domain events that cross their boundaries.

It is the reference for: where a context's responsibility ends, who depends on whom, how the SDLC flow propagates through events, and how external systems (UMS, Evolith Core, .harness, GitHub/Jira) are insulated.

Aggregate sources are defined in TAD §3; per-context tactical detail lives in each module's ddd-model.md.

2. The 9 Bounded Contexts

# Bounded Context Type Schema Tactical Model
1 Discovery Core (Phase Gate 1) tracker_discovery ddd-model
2 Design Core (Phase Gate 2) tracker_design ddd-model
3 Construction Core (Phase Gate 3) tracker_construction ddd-model
4 QA Core (Phase Gate 4) tracker_qa ddd-model
5 Release Core (Phase Gate 5) tracker_release ddd-model
6 Governance Supporting (orchestration) tracker_governance ddd-model
7 Artifacts Supporting (evidence) tracker_artifacts ddd-model
8 Metrics Supporting (analytics) tracker_metrics ddd-model
9 Integration Supporting (ACL) tracker_integration ddd-model

Classification rationale: The 5 Phase Gates are the core domain — they carry the competitive differentiator (spec-enforced SDLC governance). The 4 supporting contexts are generic/supporting subdomains that enable the core but are not themselves the differentiator.

3. Strategic Context Map (Mermaid)

flowchart TB
    subgraph external[External Systems]
        UMS[UMS SaaS<br/>AuthN/AuthZ]
        CORE[Evolith Core<br/>rulesets, artifact defs]
        HARNESS[.harness<br/>CI / contract tests]
        EXT[GitHub / Jira / Trello]
    end

    subgraph gates[Core Domain — 5 Phase Gates]
        DISC[Discovery]
        DSGN[Design]
        CONS[Construction]
        QA[QA]
        REL[Release]
    end

    subgraph support[Supporting Subdomains]
        GOV[Governance<br/>orchestrator]
        ART[Artifacts<br/>evidence]
        MET[Metrics<br/>scorecards]
        INT[Integration<br/>ACL]
    end

    %% SDLC core flow (Customer-Supplier, upstream -> downstream) via domain events
    DISC -- InitiativeApprovedEvent --> DSGN
    DSGN -- DesignApprovedEvent --> CONS
    CONS -- ConstructionGatePassedEvent --> QA
    QA -- QualityGatePassedEvent --> REL

    %% Governance orchestrates all gates (Partnership)
    GOV -. assigns work / authorizes gate .-> DISC
    GOV -. assigns work / authorizes gate .-> DSGN
    GOV -. assigns work / authorizes gate .-> CONS
    GOV -. assigns work / authorizes gate .-> QA
    GOV -. assigns work / authorizes gate .-> REL
    DISC -- gate events --> GOV
    REL -- gate events --> GOV

    %% Artifacts collects evidence from all gates (Customer-Supplier; gates = supplier)
    DISC -- artifact instances --> ART
    DSGN -- artifact instances --> ART
    CONS -- artifact instances --> ART
    QA -- artifact instances --> ART
    REL -- artifact instances --> ART

    %% Metrics consumes events from all gates (Conformist, read-only)
    gates -- domain events --> MET

    %% Integration = ACL to/from external systems
    EXT <--> INT
    INT -- ingest initiatives --> DISC
    CONS <-- PR/commit webhooks --> INT
    QA <-- test results --> HARNESS

    %% External conformist relationships
    GOV -. conformist .-> CORE
    ART -. conformist .-> CORE
    gates -. ACL .-> UMS
    support -. ACL .-> UMS
Loading

4. Relationship Catalog

Each inter-context relationship is classified by its DDD strategic pattern.

Upstream (U) Downstream (D) Pattern Integration Mechanism Boundary Contract
Discovery Design Customer-Supplier Domain event InitiativeApprovedEvent / BacklogGeneratedEvent Approved Initiative + Backlog (UUID refs)
Design Construction Customer-Supplier Domain event DesignApprovedEvent Approved TechnicalBlueprint
Construction QA Customer-Supplier Domain event ConstructionGatePassedEvent Drift-clean implementation cycle
QA Release Customer-Supplier Domain event QualityGatePassedEvent Quality gate verdict (CFR < 2%)
Governance All 5 gates Partnership / Orchestration Commands (assign agent, authorize gate) + consumes gate events PhaseGateState, SDLCExecution
All 5 gates Artifacts Customer-Supplier Domain events carrying artifact/evidence payloads ArtifactInstance, EvidenceRecord
All 5 gates Metrics Conformist (read-only) Domain events (consumed, never replied to) MetricSnapshot projections
Construction Metrics Conformist (read-only) Domain event DriftDetectedEvent DriftDetectedEventPayload — contract
Integration Discovery Anti-Corruption Layer Inbound webhook/CSV → canonical Initiative import Normalized InitiativeImport
Construction Integration Anti-Corruption Layer Outbound: GitHub/Jira PR & commit sync SyncRecord
Evolith Core Governance, Artifacts Conformist Runtime ruleset/artifact-definition fetch (immutable upstream) Core rulesets, artifact schemas
UMS All contexts Anti-Corruption Layer UmsSecurityAdapter → canonical permissions TrackerPermission
.harness QA Anti-Corruption Layer Webhook test results → TestExecutionCompletedEvent Test result contract (Pact-verified)

5. Shared Kernel

A minimal, deliberately small Shared Kernel is consumed by all contexts. Changes here require cross-context agreement.

Shared Element Nature Consumed by
Domain primitives (Entity, AggregateRoot, ValueObject, DomainEvent, Result<T>) TAD §11 All contexts
WorkflowEngine shell Cross-cutting (@evolith/workflow-engine) All gates (state machine, RequirementChecklist)
TenantConfigShell shell Cross-cutting (@evolith/tenant-config) All contexts (per-tenant workflow rules)
IntegrationFabric shell Cross-cutting (@evolith/integration-fabric) Discovery, Construction, Integration
ExternalReference VO Shared value object Discovery, Construction, QA, Integration
AuditControl VO Shared value object All contexts
Unit of Work + Event Bus + Outbox TAD §12.1, §13 All contexts

Per AGENTS.md, infrastructure plumbing must be injected via these shells — never re-implemented inside a bounded context.

6. Domain Event Flow (SDLC Propagation)

The SDLC advances through gates by published domain events. This is the canonical chain:

sequenceDiagram
    participant H as Human/Agent
    participant DISC as Discovery
    participant GOV as Governance
    participant DSGN as Design
    participant CONS as Construction
    participant QA as QA
    participant REL as Release
    participant ART as Artifacts
    participant MET as Metrics

    H->>DISC: SubmitInitiativeCommand
    DISC-->>GOV: InitiativeApprovedEvent
    DISC-->>ART: evidence (canvas, ROI)
    DISC-->>DSGN: BacklogGeneratedEvent
    GOV->>DSGN: authorize Design gate
    DSGN-->>CONS: DesignApprovedEvent
    DSGN-->>ART: evidence (contracts, ADRs)
    CONS-->>MET: CodeCommittedEvent / DriftDetectedEvent
    CONS-->>QA: ConstructionGatePassedEvent
    QA-->>REL: QualityGatePassedEvent
    QA-->>MET: TestExecutionCompletedEvent (CFR)
    REL-->>MET: DeploymentCompletedEvent (DORA)
    REL-->>ART: evidence (release notes, rollback)
Loading

Event-routing rules (per TAD §13.1):

  • Cross-context events travel via the Transactional Outbox (at-least-once); consumers are idempotent.
  • A gate never reaches into another gate's schema — it reacts to events only.
  • Governance is the only context that commands gates; all others react.

7. Anti-Corruption Layers (External Insulation)

External System ACL Owner What it translates
UMS UmsSecurityAdapter (all contexts via shell) UMS authorization graph → TrackerPermission
Evolith Core CoreIntegrationService (Governance/Artifacts) Core rulesets / artifact definitions → canonical models
.harness Integration + QA CI/test payloads → TestExecutionCompletedEvent
GitHub / GitLab Integration (GitHubAcl) Webhooks → CodeCommittedEvent, PeerReviewUpdatedEvent
Jira / Trello Integration (JiraAcl) Issues → InitiativeImport; export Backlog

No external type ever penetrates a core domain context. All translation happens at the ACL boundary (Integration context or the shared UmsSecurityAdapter).

8. Traceability

Strategic element Source
9 bounded contexts + aggregates TAD §3
Domain events per gate TAD §4–§8
Event delivery semantics TAD §13.1
Shared shells AGENTS.md, Discovery DDD §2.3
Phase Gate sequence PRD §7, Product Vision
Tenant isolation across contexts Security Spec §5

References