ddd-devops-integration

DDD DevOps 集成

面向 DDD 项目的 DevOps — 在 CI/CD 中配置 ArchUnit 质量门禁（P0 阻断 / P1 警告 / P2 报告）、多模块增量构建、感知架构类型的 Dockerfile、事件驱动的数据库迁移、领域事件健康监控。

---

工作流

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

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

步骤 3：ArchUnit 验证 — P0（零依赖、符合分层规则）阻断 CI；P1（无循环依赖）发出警告；P2（命名）生成报告。

步骤 4：集成测试 — 使用事件存储和 Outbox 进行跨模块交互测试。

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

步骤 6：部署 — 使用每个 BC 独立的命名空间、数据库迁移 init 容器和健康探针部署到 K8s。

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

质量门禁在构建时运行，绝不针对生产环境运行。违规会阻止合并，而不是阻止部署。

---

适用范围

✅ 擅长处理

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

⚠️ 需要素材

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

❌ 超出范围（不适用）

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

---

适用人群

此技能面向：后端开发人员（实现 DDD 架构）、软件架构师（评估和选择模式）、技术负责人（审查团队实现）以及 DDD 初学者（学习领域驱动设计基础知识）。

规则

1. ArchUnit P0 检查（领域纯粹性、分层合规性）失败时必须阻断 CI Pipeline。
2. Dockerfile 必须感知架构类型（单体/CQRS/六边形架构分别采用不同的构建方式）。
3. 必须在生产部署前配置领域事件监控。
4. 事件驱动系统的数据库迁移必须包含事件存储表和 Outbox 表。

---

CI/CD Pipeline

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；限制层间访问（Domain 仅允许被 Application、Infrastructure、Interface 访问）；禁止包之间存在循环依赖。完整指南：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)

构建优化：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

---

容器化部署

单体 — 多阶段 fat JAR：

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、数据库迁移 initContainers + Flyway、CQRS 拆分 HorizontalPodAutoscaler、NetworkPolicy 隔离。模板：dockerfile-patterns.md | k8s-ddd-reference.md

---

数据库迁移（事件驱动）

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';

策略：分层单数据库 → Flyway/Liquibase 顺序迁移；CQRS L2 → 双轨并行 + 延迟；事件溯源 → Axon/EventStoreDB 仅追加；每个微服务 → 每个限界上下文使用 Flyway。完整脚本：flyway-migration.md | db-strategies.md

---

监控与告警

总线指标：domain.events.published（计数器）、domain.events.processing.duration（直方图 p50/p95/p99）、domain.aggregate.load.duration（直方图）、domain.outbox.depth（仪表）。

告警规则：DomainEventBacklog（速率 > 100，持续 2m，严重）、OutboxQueueGrowing（深度 > 1000，持续 1m，严重）、EventProcessingErrorRate（> 5%，持续 2m，警告）。完整配置：ddd-observability-config.md

---

注意事项

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

---

常见问题

Q：ArchUnit CI 失败，但代码正确？ A：检查 Domain 层是否被框架注解污染（如 @Service），并将其移到基础设施层。 Q：单体与微服务的 DDD 部署策略是什么？ A：从单体开始。仅当限界上下文需要独立扩缩容、单个限界上下文团队人数 > 8 人，或限界上下文之间的部署节奏差异较大时，再进行拆分。 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 仅追加，无需 schema 迁移。通过事件版本号（event_type + version）管理版本兼容性。 Q：如何实现限界上下文的金丝雀发布？ A：使用 Service Mesh（Istio）分配流量权重。新版本先接收 5% 的流量，监控领域事件健康指标后再全量发布。

---

安全与防护

此技能纯属文档。它不会收集用户数据，不会访问外部服务或网络，也不包含可执行脚本。

关键词

ddd 运维、ddd ci/cd、archunit ci、领域事件监控、ddd docker、ddd kubernetes、ddd outbox、ddd 数据库迁移、ddd 构建优化、ddd 质量门禁、ddd 部署、ddd 告警、ddd 可观测性、cqrs 部署、事件溯源基础设施

参考资料

• CI/CD ArchUnit 配置 — ArchUnit CI/CD 集成指南
• Dockerfile 模式 — 按 DDD 架构类型划分的 Dockerfile
• K8s DDD 参考 — 限界上下文的 K8s 部署
• Flyway 领域事件迁移 — 事件存储和 outbox 脚本
• 监控与告警 — Prometheus 指标和告警规则
• 多模块构建配置 — Maven/Gradle 构建优化
• DDD 可观测性配置 — Micrometer/OTel/Logback 配置
• GitLab CI Pipeline 参考 — 完整的 GitLab CI pipeline
• 数据库迁移策略 — 事件驱动迁移策略

示例

• GitHub Actions Pipeline — 包含 ArchUnit 的完整 GitHub Actions 工作流
• GitLab CI ArchUnit Pipeline — 带架构验证的 GitLab CI
• K8s DDD 部署 — 用于部署限界上下文的 K8s 清单
• Flyway 领域事件迁移 — 完整的迁移 SQL 脚本
• Grafana 领域健康仪表板 — 领域事件监控仪表板