DDD诊所——聚合过大综合症

“DDD诊所”是Thoughtworks DDD社区的一项活动，通过对同事们在实施DDD过程中遇到的问题进行分析和解答，共同提高开发水平。我们将其中一些典型案例整理成文供大家参考。之后也会考虑在适当的时候将这一形式对外部开放。

就诊日期：2022年6月8日

患者：某DevOps平台持续集成模块

诊金：0元（免费义诊）

【患者主诉】

疑似问题设计

某DevOps平台需提供持续交付流水线设计功能，使用户可在界面上规划完整流程。因此，流水线设计页面功能繁杂，涵盖阶段规划、前置触发条件设置、质量门禁控制等。随着功能扩展，页面复杂度逐渐提升。此类功能旨在协助用户优化持续交付流水线管理，提升交付效能与质量。

持续交付流水线界面原

功能介绍：

1. 设计不同的阶段：用户可以根据需要设置不同的阶段，例如开发阶段、测试阶段等。对于每个阶段，用户可以设置不同的步骤，例如Checkout、编译、构建镜像和部署等。

2. 设计前置触发条件：用户可以选择两种触发方式，一种是某个代码仓库提交触发，另一种是定时任务。用户可以设置多个前置触发条件。

3. 设置质量门禁：用户可以选择给阶段设置质量门禁，例如单元测试覆盖率大于80%等。这些门禁指标可以在质量门禁管理功能中设置。在流水线执行时，如果不满足门禁指标，会阻止流水线进入下一个阶段。

项目架构师在接到需求后，根据需求设计了一个名为“持续交付流水线领域模型”。该模型的目的是方便用户在界面上完成一系列操作，如代码质量检查、编译代码、构建镜像和部署等。这些操作被看作是一个整体，并被组织在一个叫做“流水线”的聚合中。这个聚合包括质量门禁、不同的阶段和触发规则等。这种设计旨在保证流水线中各个组成部分的一致性。

请注意，图中的“<>”是一种自定义的衍生关系，意味着该对象映射自其他上下文。

持续交付流水线领域模型

团队按照这个模型落地了代码，随着交付的深入，这个模型的缺点也浮现出来。

引发问题

1. 认知负载上升

这个