Back to Details

ddd-devops-integration

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

DDD DevOps Integration

DDD DevOps 集成

DevOps for DDD projects — ArchUnit quality gates (P0 block / P1 warn / P2 report) in CI/CD, multi-module incremental builds, architecture-type-aware Dockerfiles, event-driven DB migration, domain event health monitoring.
面向 DDD 项目的 DevOps——在 CI/CD 中实施 ArchUnit 质量门禁（P0 阻断 / P1 警告 / P2 报告），支持多模块增量构建、架构类型感知的 Dockerfile、事件驱动的 DB 迁移，以及领域事件健康监控。

Workflow

工作流

Step 1: Code & Build — Compile all modules. Domain must compile last (zero framework contamination).

第 1 步：代码与构建——编译所有模块。Domain 必须最后编译（零框架污染）。

Step 2: Unit Test — Per-module unit tests run independently.

第 2 步：单元测试——各模块的单元测试独立运行。

Step 3: ArchUnit Validate — P0 (zero deps, layer compliance) blocks CI; P1 (cycle-free) warns; P2 (naming) reports.

第 3 步：ArchUnit 校验——P0（零依赖、分层合规）阻断 CI；P1（无循环依赖）警告；P2（命名规范）报告。

Step 4: Integration Test — Cross-module interaction tests with event store and outbox.

第 4 步：集成测试——使用 Event Store 和 Outbox 进行跨模块交互测试。

Step 5: Containerize — Build Docker images (monolith fat JAR or split CQRS with tuned JVM args).

第 5 步：容器化——构建 Docker 镜像（单体 fat JAR，或使用调优后的 JVM 参数拆分 CQRS）。

Step 6: Deploy — K8s deploy with per-BC namespace, DB migration init containers, health probes.

第 6 步：部署——通过 K8s 部署，每个 BC 使用独立 Namespace，并配置 DB 迁移 initContainers 和健康探针。

Step 7: Monitor — Domain metrics (event rate, outbox depth, aggregate load) → Prometheus alerts.

第 7 步：监控——领域指标（事件速率、Outbox 深度、聚合加载）→ Prometheus 告警。

Quality gates run at build time, never against production. Violations block merge, not deployment.
质量门禁在构建时运行，绝不会针对生产环境运行。违规项会阻断合并，而不是部署。

Boundary

边界

✅ 擅长处理

✅ 擅长处理

  • 为 DDD 项目配置 ArchUnit 质量门禁（P0/P1/P2），集成到 CI/CD Pipeline
  • 多模块 DDD 项目增量编译优化（Maven/Gradle）、并行构建加速
  • 架构类型感知的 Dockerfile 生成（单体/CQRS/六边形架构）
  • K8s 部署模板：Per-BC Namespace、DB 迁移 initContainers、领域健康探针
  • 事件驱动数据库迁移：Event Store、Outbox 表创建与索引策略
  • 领域事件健康监控：Prometheus 指标暴露与告警规则配置
  • 为 DDD 项目配置 ArchUnit 质量门禁（P0/P1/P2），集成到 CI/CD Pipeline
  • 多模块 DDD 项目增量编译优化（Maven/Gradle）、并行构建加速
  • 架构类型感知的 Dockerfile 生成（单体/CQRS/六边形架构）
  • K8s 部署模板：Per-BC Namespace、DB 迁移 initContainers、领域健康探针
  • 事件驱动数据库迁移：Event Store、Outbox 表创建与索引策略
  • 领域事件健康监控：Prometheus 指标暴露与告警规则配置

⚠️ 需要素材

⚠️ 需要素材

  • 项目结构：Maven/Gradle 模块列表、依赖关系图 → 自动生成 ArchUnit 规则
  • 部署环境：K8s 集群版本、Ingress 策略 → 生成适配的 YAML 模板
  • 数据库方案：采用 Layered/CQRS/Event Sourcing 何种模式 → 定制迁移策略
  • 项目结构：Maven/Gradle 模块列表、依赖关系图 → 自动生成 ArchUnit 规则
  • 部署环境：K8s 集群版本、Ingress 策略 → 生成适配的 YAML 模板
  • 数据库方案：使用 Layered/CQRS/Event Sourcing 中的哪种模式 → 定制迁移策略

❌ 超出范围（不适用）

❌ 超出范围（不适用）

  • 通用 CI/CD 配置（非 DDD 项目不适用）→ 使用通用 DevOps 工具
  • 容器编排基础（K8s 入门教程）→ 参考官方文档
  • K8s 集群运维（节点管理、RBAC 配置）→ 使用专业运维工具
  • 通用数据库管理（备份、恢复、性能调优）→ 使用 DBA 工具
  • 基础设施监控（CPU、内存、网络）→ 使用 Prometheus + Grafana
  • 通用 CI/CD 配置（非 DDD 项目不适用）→ 使用通用 DevOps 工具
  • 容器编排基础（K8s 入门教程）→ 参考官方文档
  • K8s 集群运维（节点管理、RBAC 配置）→ 使用专业运维工具
  • 通用数据库管理（备份、恢复、性能调优）→ 使用 DBA 工具
  • 基础设施监控（CPU、内存、网络）→ 使用 Prometheus + Grafana

Audience

适用受众

This skill is designed for: Backend developers (implementing DDD architectures), Software architects (evaluating and selecting patterns), Tech leads (reviewing team implementations), and DDD beginners (learning domain-driven design fundamentals).
此 skill 专为以下人群设计：后端开发者（实现 DDD 架构）、软件架构师（评估和选择模式）、技术负责人（审查团队实现）以及 DDD 初学者（学习领域驱动设计基础）。

Rules

规则

  1. ArchUnit P0 checks (domain purity, layer compliance) must block CI pipeline on failure.
  2. Dockerfiles must be architecture-type-aware (Monolith/CQRS/Hexagonal each get different builds).
  3. Domain event monitoring must be configured before production deployment.
  4. Database migrations for event-driven systems must include event store and outbox tables.
  1. ArchUnit P0 检查（领域纯度、分层合规性）失败时必须阻断 CI Pipeline。
  2. Dockerfile 必须能够感知架构类型（Monolith/CQRS/Hexagonal 分别采用不同的构建方式）。
  3. 生产部署前必须配置领域事件监控。
  4. 事件驱动系统的数据库迁移必须包含 Event Store 和 Outbox 表。

CI/CD Pipeline

CI/CD Pipeline

yaml
stages:
  - build
  - unit-test
  - architecture-check    # DDD gate
  - integration-test
  - containerize
  - deploy
ArchUnit validation in 
architecture-check
stage: P0 tests (
DomainPurityTest
, 
LayeringComplianceTest
) block on failure; P1 (
ModuleDependencyTest
) warns with approval; P2 (
NamingConventionTest
) reports only. Key ArchUnit rules — domain must not depend on Spring/JPA/MyBatis; layer access restrictions (Domain only by Application, Infrastructure, Interface); no cyclic package dependencies. Full guide: references/ci-cd-archunit-setup.md
yaml
stages:
  - build
  - unit-test
  - architecture-check    # DDD gate
  - integration-test
  - containerize
  - deploy
architecture-check
阶段中的 ArchUnit 校验：P0 测试（
DomainPurityTest
、
LayeringComplianceTest
）失败时阻断；P1（
ModuleDependencyTest
）发出警告并要求审批；P2（
NamingConventionTest
）仅报告。关键 ArchUnit 规则——Domain 不得依赖 Spring/JPA/MyBatis；层级访问限制（仅 Application、Infrastructure、Interface 可访问 Domain）；不允许循环包依赖。完整指南：references/ci-cd-archunit-setup.md

多模块构建策略

多模块构建策略

ddd-project/
├── domain/ (zero framework deps) → application/ (depends on domain only) → infrastructure/ (implements domain interfaces)
├── adapter/ (REST/event adapters) → start/ (boot entry)
Build optimization: 
mvn compile -pl domain -am
(~60% faster changed-only), 
mvn -T 4
(~40% parallel), 
mvn verify -pl '!domain'
(skip domain), 
actions/cache
for 
target/
(~80%). Domain purity enforced via Maven Enforcer (bans Spring deps in domain module). Full config: references/multi-module-build-config.md
ddd-project/
├── domain/ (zero framework deps) → application/ (depends on domain only) → infrastructure/ (implements domain interfaces)
├── adapter/ (REST/event adapters) → start/ (boot entry)
构建优化：
mvn compile -pl domain -am
（仅编译发生变更的模块，速度约提升 60%）、
mvn -T 4
（并行构建，速度约提升 40%）、
mvn verify -pl '!domain'
（跳过 Domain）、通过 
actions/cache
缓存 
target/
（速度约提升 80%）。通过 Maven Enforcer 强制 Domain 纯净性（禁止 Domain 模块引入 Spring 依赖）。完整配置：references/multi-module-build-config.md

容器化部署

容器化部署

Monolith — Multi-stage fat JAR:
dockerfile
FROM eclipse-temurin:17-jdk-alpine AS builder
COPY . . && RUN mvn clean package -DskipTests
FROM eclipse-temurin:17-jre-alpine
COPY --from=builder start/target/*.jar app.jar
HEALTHCHECK --interval=30s CMD curl -f http://localhost:8080/actuator/health
CQRS — Separate images: Command (
-Xms512m -Xmx2g -XX:+UseZGC
, CPU-optimized); Query (
-Xms1g -Xmx4g
, memory-optimized). K8s Patterns: Per-BC 
Namespace
, DB migration 
initContainers
+ Flyway, CQRS split 
HorizontalPodAutoscaler
, 
NetworkPolicy
isolation. Templates: dockerfile-patterns.md | k8s-ddd-reference.md
单体（Monolith）——Multi-stage fat JAR：
dockerfile
FROM eclipse-temurin:17-jdk-alpine AS builder
COPY . . && RUN mvn clean package -DskipTests
FROM eclipse-temurin:17-jre-alpine
COPY --from=builder start/target/*.jar app.jar
HEALTHCHECK --interval=30s CMD curl -f http://localhost:8080/actuator/health
CQRS——独立镜像：Command（
-Xms512m -Xmx2g -XX:+UseZGC
，针对 CPU 优化）；Query（
-Xms1g -Xmx4g
，针对内存优化）。K8s 模式：每个 BC 使用独立 
Namespace
，DB 迁移使用 
initContainers
+ Flyway，CQRS 拆分使用 
HorizontalPodAutoscaler
，通过 
NetworkPolicy
隔离。模板：dockerfile-patterns.md | k8s-ddd-reference.md

数据库迁移（事件驱动）

数据库迁移（事件驱动）

sql
CREATE TABLE domain_event_store (id UUID PRIMARY KEY, aggregate_id VARCHAR(36) NOT NULL,
    event_type VARCHAR(200) NOT NULL, event_data JSONB NOT NULL,
    occurred_at TIMESTAMPTZ NOT NULL, published BOOLEAN DEFAULT FALSE);
CREATE INDEX idx_events_pending ON domain_event_store(published) WHERE published = FALSE;
CREATE TABLE outbox_message (id UUID PRIMARY KEY, event_id UUID UNIQUE NOT NULL,
    payload JSONB NOT NULL, status VARCHAR(20) DEFAULT 'PENDING',
    retry_count INT DEFAULT 0, created_at TIMESTAMPTZ DEFAULT NOW());
CREATE INDEX idx_outbox_pending ON outbox_message(status) WHERE status = 'PENDING';
Strategy: Layered single DB → Flyway/Liquibase sequential; CQRS L2 → Dual tracks + lag; Event Sourcing → Axon/EventStoreDB append-only; Per microservice → Per-BC Flyway. Full scripts: flyway-migration.md | db-strategies.md
sql
CREATE TABLE domain_event_store (id UUID PRIMARY KEY, aggregate_id VARCHAR(36) NOT NULL,
    event_type VARCHAR(200) NOT NULL, event_data JSONB NOT NULL,
    occurred_at TIMESTAMPTZ NOT NULL, published BOOLEAN DEFAULT FALSE);
CREATE INDEX idx_events_pending ON domain_event_store(published) WHERE published = FALSE;
CREATE TABLE outbox_message (id UUID PRIMARY KEY, event_id UUID UNIQUE NOT NULL,
    payload JSONB NOT NULL, status VARCHAR(20) DEFAULT 'PENDING',
    retry_count INT DEFAULT 0, created_at TIMESTAMPTZ DEFAULT NOW());
CREATE INDEX idx_outbox_pending ON outbox_message(status) WHERE status = 'PENDING';
策略：Layered 单数据库 → Flyway/Liquibase 顺序迁移；CQRS L2 → 双轨 + lag；Event Sourcing → Axon/EventStoreDB append-only；每个微服务 → Per-BC Flyway。完整脚本：flyway-migration.md | db-strategies.md

监控与告警

监控与告警

Bus metrics: 
domain.events.published
(Counter), 
domain.events.processing.duration
(Histogram p50/p95/p99), 
domain.aggregate.load.duration
(Histogram), 
domain.outbox.depth
(Gauge).
Alert rules: DomainEventBacklog (rate > 100 for 2m, critical), OutboxQueueGrowing (depth > 1000 for 1m, critical), EventProcessingErrorRate (> 5% for 2m, warning). Full config: ddd-observability-config.md
Bus 指标：
domain.events.published
（Counter）、
domain.events.processing.duration
（Histogram，p50/p95/p99）、
domain.aggregate.load.duration
（Histogram）、
domain.outbox.depth
（Gauge）。
告警规则：DomainEventBacklog（速率 > 100 持续 2m，critical）、OutboxQueueGrowing（深度 > 1000 持续 1m，critical）、EventProcessingErrorRate（> 5% 持续 2m，warning）。完整配置：ddd-observability-config.md

Gotchas

常见问题与注意事项

  1. ArchUnit 过严导致开发受阻: 先用 warning 模式运行 2-3 个 sprint，P1/P2 不阻断 CI，团队适应后升级为 error。
  2. CQRS 读写容器未分离: 命令服务 CPU 密集，查询服务内存密集，应独立构建部署。
  3. 领域事件监控遗漏: Event 投递延迟、Outbox 堆积、Consumer Lag 是事件驱动架构中最易忽略的可靠性指标。
  4. 单体打成微服务镜像: 先评估 BC 是否需要独立部署，过度拆分失去聚合内强一致性优势。
  5. 数据库迁移未考虑事件存储: 添加 Event Store 表时需同步考虑回填、索引、清理策略。
  6. ArchUnit 不检查充血模型: 需结合 ddd-code-reviewer 做领域模型质量审查。
  1. ArchUnit 过严导致开发受阻：先以 warning 模式运行 2-3 个 sprint，P1/P2 不阻断 CI，团队适应后再升级为 error。
  2. CQRS 读写容器未分离：命令服务 CPU 密集，查询服务内存密集，应独立构建和部署。
  3. 领域事件监控遗漏：Event 投递延迟、Outbox 堆积和 Consumer Lag 是事件驱动架构中最容易忽略的可靠性指标。
  4. 单体打成微服务镜像：先评估 BC 是否需要独立部署；过度拆分会失去聚合内的强一致性优势。
  5. 数据库迁移未考虑事件存储：添加 Event Store 表时，需要同步考虑回填、索引和清理策略。
  6. ArchUnit 不检查充血模型：需结合 ddd-code-reviewer 进行领域模型质量审查。

FAQ

FAQ

Q: ArchUnit CI 失败但代码正确？ A: 检查 Domain 层是否有框架注解污染（如 
@Service
），移到基础设施层。 Q: Monolith vs 微服务 DDD 部署策略？ A: 从单体开始。仅当 BC 需独立扩缩容、单 BC 团队 > 8 人、BC 间部署节奏差异大时再拆分。 Q: 如何监控领域事件而不增加延迟？ A: 异步指标（Micrometer Timer 百分比采样）+ 采样追踪（1/100 OpenTelemetry）。绝不阻塞事件发布。 Q: CQRS 读写应共享同一 pipeline？ A: 只共享 Domain 模块测试。Command pipeline 跑完整 ArchUnit 门禁；Query pipeline 聚焦读模型 schema 兼容性。 Q: Event Sourcing schema 如何管理？ A: Event Store append-only，不需 schema 迁移。版本兼容性通过事件版本号（event_type + version）管理。 Q: Bounded Context 金丝雀发布如何实现？ A: Service Mesh（Istio）流量权重分配。新版本先接 5% 流量，监控 domain event 健康指标后全量。
问：ArchUnit CI 失败但代码正确？ 答：检查 Domain 层是否存在框架注解污染（如 
@Service
），并将其移至基础设施层。 问：Monolith 与微服务 DDD 部署策略？ 答：从单体开始。仅当 BC 需要独立扩缩容、单个 BC 团队 > 8 人，或 BC 之间部署节奏差异较大时再拆分。 问：如何监控领域事件而不增加延迟？ 答：使用异步指标（Micrometer Timer 百分位采样）+ 采样追踪（1/100 OpenTelemetry）。绝不阻塞事件发布。 问：CQRS 读写应共享同一 pipeline？ 答：仅共享 Domain 模块测试。Command pipeline 运行完整的 ArchUnit 门禁；Query pipeline 聚焦读模型 schema 兼容性。 问：Event Sourcing schema 如何管理？ 答：Event Store 采用 append-only，不需要 schema 迁移。版本兼容性通过事件版本号（event_type + version）管理。 问：Bounded Context 金丝雀发布如何实现？ 答：使用 Service Mesh（Istio）分配流量权重。新版本先接收 5% 流量，监控 domain event 健康指标后再全量发布。

Security & Safety

安全与防护

This skill is pure documentation. It does not collect user data, does not access external services or networks, and contains no executable scripts.
此 skill 纯属文档形式。它不收集用户数据，不访问外部服务或网络，也不包含可执行脚本。

Keywords

关键词

ddd devops, ddd ci/cd, archunit ci, domain event monitoring, ddd docker, ddd kubernetes, ddd outbox, ddd database migration, ddd build optimization, ddd quality gate, ddd deployment, ddd alerting, ddd observability, cqrs deployment, event sourcing infrastructure
ddd devops, ddd ci/cd, archunit ci, 领域事件监控, ddd docker, ddd kubernetes, ddd outbox, ddd 数据库迁移, ddd 构建优化, ddd 质量门禁, ddd 部署, ddd 告警, ddd 可观测性, cqrs 部署, 事件溯源基础设施

References

参考资料

  • CI/CD ArchUnit Setup — ArchUnit CI/CD integration guide
  • Dockerfile Patterns — Dockerfiles by DDD architecture type
  • K8s DDD Reference — K8s deployment for bounded contexts
  • Flyway Domain Event Migration — Event store and outbox scripts
  • Monitoring & Alerting — Prometheus metrics and alerting rules
  • Multi-Module Build Config — Maven/Gradle build optimization
  • DDD Observability Config — Micrometer/OTel/Logback configuration
  • GitLab CI Pipeline Reference — GitLab CI complete pipeline
  • Database Migration Strategies — Event-driven migration strategies
  • CI/CD ArchUnit 配置 — ArchUnit CI/CD 集成指南
  • Dockerfile 模式 — 按 DDD 架构类型划分的 Dockerfile
  • K8s DDD 参考 — 面向 Bounded Context 的 K8s 部署
  • Flyway 领域事件迁移 — Event Store 和 Outbox 脚本
  • 监控与告警 — Prometheus 指标和告警规则
  • 多模块构建配置 — Maven/Gradle 构建优化
  • DDD 可观测性配置 — Micrometer/OTel/Logback 配置
  • GitLab CI Pipeline 参考 — 完整的 GitLab CI Pipeline
  • 数据库迁移策略 — 事件驱动迁移策略

Examples

示例

  • GitHub Actions Pipeline — Complete GitHub Actions workflow with ArchUnit
  • GitLab CI ArchUnit Pipeline — GitLab CI with architecture validation
  • K8s DDD Deployment — K8s manifests for bounded context deployment
  • Flyway Domain Event Migration — Complete migration SQL scripts
  • Grafana Domain Health Dashboard — Domain event monitoring dashboard
  • GitHub Actions Pipeline — 包含 ArchUnit 的完整 GitHub Actions 工作流
  • GitLab CI ArchUnit Pipeline — 包含架构校验的 GitLab CI
  • K8s DDD 部署 — 面向 Bounded Context 的 K8s manifests
  • Flyway 领域事件迁移 — 完整迁移 SQL 脚本
  • Grafana 领域健康仪表盘 — 领域事件监控仪表盘