Skip to content

Latest commit

 

History

History
158 lines (130 loc) · 5.32 KB

File metadata and controls

158 lines (130 loc) · 5.32 KB

DDD Model - Release Module

Bilingual Navigation: English (this document) · Versión en Español Required Phase: Phase 5 — Delivery (Release) Primary Audience: DevOps, Release Managers, SRE, Architects

1. Ubiquitous Language

Strict terminology shared between business and technical domains within this context:

  • Release Package: Groups a set of Technical Stories and User Stories (generate mode) or validated initiative checkpoints (initiative-only mode) that have been validated by QA and are ready for Production.
  • Environment: The logical or physical target (e.g., Staging, UAT, Production) where code operates.
  • Deployment Record: Immutable trace of a physical deployment activity towards an Environment.
  • Release Notes: Official artifact for executive communication of delivered value.

2. Conceptual Maps and Aggregates (Mermaid)

2.0. Visual Legends and Glossary

Symbol/Stereotype Meaning
<<Aggregate Root>> Transactional root entity. Governs the persistence of its internal entities.
<<Value Object>> Immutable object without intrinsic identity. Represents a structural property.
*-- (Solid line) Composition. The child element cannot exist without the parent.
..> (Dotted line) Dependency. The element interacts with or delegates to another component.

2.1. View 1: Business Core (Aggregates and Entities)

classDiagram
    class ReleasePackage {
        <<Aggregate Root>>
        +UUID id
        +String tenantId
        +String versionNumber
        +String releaseNotes
        +ReleaseStatus status
        +UUID releaseManagerId_umsUserId
        +List~UUID~ validatedStoryIds
        +List~UUID~ validatedCheckpointIds?
        +List~ExternalReference~ externalRefs
        +generateReleaseNotes(UUID umsUserId)
        +approveDeployment(ReleaseGate, UUID umsUserId)
        +markAsDeployed(UUID umsUserId)
    }
    note for ReleasePackage "In generate mode, validatedStoryIds is populated with validated story IDs. In initiative-only mode, validatedCheckpointIds is populated with validated checkpoint IDs."

    class DeploymentRecord {
        <<Aggregate Root>>
        +UUID id
        +UUID releasePackageId
        +UUID environmentId
        +UUID deployedById_umsUserId
        +Date deploymentDate
        +DeploymentStatus status
        +String rollbackUrl
        +List~ExternalReference~ externalRefs
        +logDeployment(DeploymentStatus status, UUID umsUserId)
        +triggerRollback(UUID umsUserId)
    }

    class Environment {
        <<Entity>>
        +UUID id
        +String name
        +EnvironmentType type
    }

    class ExternalReference {
        <<Value Object>>
        +ExternalSystem system
        +String externalId
        +String url
        +ReferenceType type
        +String label
        +Date linkedAt
        +Map metadata
    }

    ReleasePackage "1" --> "0..*" DeploymentRecord : originates
    ReleasePackage "1" *-- "1..*" Environment : defines targets
    ReleasePackage "1" *-- "0..*" ExternalReference : mapped to
    DeploymentRecord "1" *-- "0..*" ExternalReference : mapped to
Loading

2.2. View 2: Workflow and Audit Components

classDiagram
    class AuditControl {
        <<Value Object>>
        +String createdBy
        +Date createdAt
    }

    class ReleaseGate {
        <<Value Object>>
        +String approvedById_umsUserId
        +GateDecision decision
        +Date decidedAt
    }

    class StateTransition {
        <<Value Object>>
        +ReleaseStatus fromState
        +ReleaseStatus toState
        +Date transitionDate
    }

    class ReleasePackage {
        <<Aggregate Root>>
    }

    ReleasePackage "1" *-- "1" AuditControl : tracked by
    ReleasePackage "1" *-- "0..1" ReleaseGate : governed by
    ReleasePackage "1" *-- "0..*" StateTransition : workflow history
Loading

2.3. View 3: Cross-Cutting Infrastructure (Shells)

classDiagram
    class IntegrationFabric {
        <<Shared Kernel Shell>>
        +triggerCDPipeline()
        +listenToWebhook()
    }

    class TenantConfigShell {
        <<Shared Kernel Shell>>
        +getReleasePolicies()
    }

    class UMS_SDK {
        <<Cross-Cutting>>
        +RequiresDomainAccess()
    }

    class ReleasePackage {
        <<Aggregate Root>>
    }

    class DeploymentRecord {
        <<Aggregate Root>>
    }

    ReleasePackage ..> TenantConfigShell : reads policies
    ReleasePackage ..> UMS_SDK : secured via
    DeploymentRecord ..> IntegrationFabric : asynchronously hydrated by (e.g., Jenkins/Harness)
Loading

3. Tactical Design

3.1. Independent Aggregate Roots (Anti-Deadlock)

  • DeploymentRecord: Elevated to an Aggregate Root so CI/CD platforms (GitHub Actions, Jenkins, Harness) can update deployment status (SUCCESS/FAILED) asynchronously without locking the parent ReleasePackage.
  • Toggle Management: By corporate definition, Evolith Tracker focuses on SDLC governance. "Feature Toggles" are considered a purely operational external concern, and thus are not modeled within the Tracker.

3.2. Secure UMS and ALM Mapping

Release orchestrators (releaseManagerId_umsUserId, deployedById_umsUserId) are strictly typed. This allows safe tracking and granular authorization for approveDeployment(). CI/CD tools connect natively via ExternalReference.