Skip to content

Bounded Contexts

The DevOps / GitOps Platform is decomposed into six bounded contexts, each owning a coherent slice of the delivery lifecycle and a disjoint set of aggregate roots. Contexts communicate only through the canonical event envelope and well-defined APIs — never by sharing a database.

Target Architecture — Final-State Design

The boundaries below are the target decomposition. They map one-to-one onto the platform's 14 microservices and 15 aggregate roots, preserving a clean separation of concerns for autonomy and independent scale.

Context Map

flowchart TB
    subgraph SourceControl["Source Control"]
        direction TB
        scAgg["Repository, Branch, Commit, PullRequest"]
    end
    subgraph Pipelines["Pipelines"]
        direction TB
        plAgg["PipelineDefinition, PipelineRun, BuildResult"]
    end
    subgraph Release["Release and Promotion"]
        direction TB
        relAgg["ReleasePlan, ReleaseApproval, EnvironmentPromotion, DeploymentManifest"]
    end
    subgraph Packaging["Packaging"]
        direction TB
        pkgAgg["PackagePublication, ContainerImage"]
    end
    subgraph Infrastructure["Infrastructure"]
        direction TB
        infAgg["InfrastructurePlan"]
    end
    subgraph GitOpsSync["GitOps Sync"]
        direction TB
        gitAgg["GitOpsSyncState"]
    end

    SourceControl -->|"CommitCreated, PullRequestMerged"| Pipelines
    Pipelines -->|"BuildCompleted"| Packaging
    Pipelines -->|"BuildCompleted"| Release
    Release -->|"ReleaseApproved"| Infrastructure
    Release -->|"DeploymentPromoted"| GitOpsSync
    Infrastructure -->|"InfrastructureProvisioned"| GitOpsSync
    Packaging -->|"artifacts ready"| Release
Hold "Alt" / "Option" to enable pan & zoom

Context Catalog

Bounded Context Responsibility Aggregate Roots Microservices Upstream Downstream
Source Control Repository provisioning, branching, commits, and pull-request workflows on Azure DevOps Git. Repository, Branch, Commit, PullRequest RepositoryService, BranchService, CommitService, PullRequestService Agent Mesh, Template & Library Pipelines
Pipelines Generate, execute, and observe CI/CD pipelines; capture build results. PipelineDefinition, PipelineRun, BuildResult PipelineGeneratorService, PipelineExecutionService, BuildResultService Source Control Packaging, Release
Release & Promotion Plan releases, gate with approvals, render manifests, promote across environments. ReleasePlan, ReleaseApproval, EnvironmentPromotion, DeploymentManifest ReleaseService, EnvironmentPromotionService, DeploymentManifestService Pipelines, Packaging Infrastructure, GitOps Sync
Packaging Publish NuGet packages to Azure Artifacts; build and push container images to ACR. PackagePublication, ContainerImage PackagePublishingService, ContainerImageService Pipelines Release
Infrastructure Provision cloud infrastructure via Pulumi (.NET/C#) programs with preview, apply, and drift detection. InfrastructurePlan IaCProvisioningService Release GitOps Sync
GitOps Sync Continuously reconcile running state with desired state declared in Git. GitOpsSyncState GitOpsSyncService Release, Infrastructure Runtime & Cloud

Context Relationships

  • Source Control → Pipelines — a merged pull request (PullRequestMerged) or new commit (CommitCreated) triggers pipeline execution. Customer/supplier relationship; Pipelines is the customer.
  • Pipelines → Packaging — BuildCompleted releases produced artifacts for publication. Packaging is downstream.
  • Pipelines → Release & Promotion — a successful build makes a release plannable.
  • Packaging → Release & Promotion — published packages and images become release inputs.
  • Release & Promotion → Infrastructure — an approved release that requires new or updated infrastructure invokes Pulumi provisioning.
  • Release & Promotion → GitOps Sync & Infrastructure → GitOps Sync — desired-state changes are committed to Git; the GitOps Sync context reconciles them onto the Runtime & Cloud Platform.

Anti-Corruption & Shared Kernel

  • The canonical event envelope and the naming conventions form the shared kernel across all six contexts.
  • External systems (Azure DevOps REST, GitHub, ACR, Azure Artifacts, cloud provider APIs) are reached through anti-corruption adapters owned by the Integration Platform, keeping context domain models free of vendor concepts.

Pillar Alignment

  • Reusability — each context is independently versioned and reusable across tenants and projects.
  • Governance — the Release & Promotion context is the single place where approval policy is enforced.
  • Traceability — cross-context communication carries traceId, so a deployment can be traced back to its originating commit and artifact.