22、软件领域划分与事件风暴应用指南

最新推荐文章于 2025-09-27 00:57:53 发布

r2s3t4

最新推荐文章于 2025-09-27 00:57:53 发布

阅读量45

点赞数

CC 4.0 BY-SA版权

分类专栏：架构现代化：从负债到竞争优势的转变文章标签：软件架构设计子域拆分关键过渡点

本文链接：https://blog.youkuaiyun.com/r2s3t4/article/details/149650853

架构现代化：从负债到竞争优势的转变专栏收录该内容

22 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

软件领域划分与事件风暴应用指南

1. 长期思考与子域拆分

在软件架构设计中，从长远角度思考是很有必要的。当子域不断发展壮大，单一团队难以有效管理时，基于角色进行拆分或许是理想的方法。为了做好准备，在代码中应保持与规范相关和与执行相关的概念松散耦合。

2. 关键过渡点拆分

目的的转变往往伴随着一个明确的过渡时刻。可以通过提问 “具体在什么时候……？” 来应用这一启发式方法，例如 “一个人何时成为成年人？” 在英国法律中，答案是 “一个人在 18 岁生日当天成为成年人”，这就是过渡点。在此之前，这个人被定义为未成年人；之后，则被定义为成年人。这种提问方式有时能揭示深刻的见解，建议在研讨会中使用。

另一个关键过渡点的标志是一个流程或子流程结束，另一个开始，通常伴随着人员或角色的交接。以餐厅厨房为例：
| 步骤 | 描述 |
| — | — |
| 1 | 顾客在餐桌就座并下单 |
| 2 | 服务员生成订单 |
| 3 | 开胃菜厨师开始准备开胃菜 |
| 4 | 服务员清理餐桌上的开胃菜后，主菜厨师开始准备主菜 |

graph LR
    A[顾客就座下单] --> B[服务员生成订单]
    B --> C[开胃菜厨师准备开胃菜]
    C --> D[服务员清理开胃菜]
    D --> E[主菜厨师准备主菜]

3. 子域分组启发式方法

无论如何在子域级别划分领域边界以创建松散耦合的软件和独立团队，它们之间总会存在一些依赖关系。良好的领域边界可以最大限度地减少不必要的耦合，但无法完全消除。在实现新功能或交付某些类型的工作时，多个子域、代码库和团队之间有时会发生协同变更。通过识别具有密切关系的子域并将它们分组到范围 2 域中，可以降低耦合成本。

将子域分组到更高级别的域中，具有以下好处：
- 一起变更的子域将由一起工作的团队负责，向同一领导结构汇报，并朝着相同的业务成果努力。
- 团队之间的沟通自然会更频繁，协作障碍也会更低。

从 Vladik 的耦合公式角度来看，这是一种有意采取的行动，可以减少具有高速度的子域之间的距离。

4. 子域分组的不同方式

产品或服务聚焦域 ：由致力于为单一产品或服务提供功能的子域组成。这种启发式方法通常会促进单一产品内变更的快速流动，但可能会忽视多个产品的用户体验，并且重复程度可能很高。对于具有极高复杂度产品的组织，可能需要考虑产品能力聚焦域，即由为单一大型产品的某个部分提供功能的子域组成。
水平域 ：由为多个其他域所利用的平台提供功能的子域组成。适当使用这种启发式方法可以降低成本、复杂性和上市时间，但也存在一些潜在问题，如成为瓶颈、接口设计不佳和可靠性差等。例如，Uber 的履约平台投入了大量精力来解决这些问题。
流程或旅程聚焦域 ：由致力于提供实现端到端流程或旅程所需的所有功能的子域组成。这种方法通常会促进团队间变更的快速流动，并共同负责创建优化的用户体验。例如，商业财产税案例中，多个团队负责流程的不同步骤，共同关注端到端流程。
客户或用户聚焦域 ：由致力于为单一类型的客户或用户提供功能的子域组成。这种方法鼓励团队专注于特定类型客户或用户的需求，但可能难以将每个子域都归类到某一类型的用户。例如，OpenTable 在现代化过程中就遇到了部分业务涉及多种用户类型的问题。
地理聚焦域 ：由仅为特定地理区域提供功能的子域组成。这种方法在需要不同地区快速变更和更大自由的场景中很有用，但需要平衡地理区域内更大自主性的成本与重复成本以及多地区客户可能注意到的不一致性。

5. 航空公司领域分解实例

2015 年，一家大型航空公司启动了现代化之旅，目标是实现差异化的客户体验、加速创新和交付速度、挖掘未开发的收入机会以及降低成本提高运营绩效。其现有的架构是一个难以更改的大泥球单体应用，部署困难，可靠性低，缺乏日志记录、监控和可观测性。

Javier Laso 和她的同事通过事件风暴会议了解当前状态，探索未来机会和领域边界。他们确定了目标域和子域，包括报价/订购域、兑换和忠诚度域、值机与登机域以及由三个子域组成的行程管理域。这些域的命名遵循领域术语，经过多方利益相关者的共同定义，有助于展现每个域中子域的内聚性。

例如，报价/订购域的目的是提供客户可购买的报价，并处理预订和履行流程。每个关注点都被建模为一个单独的子域，因为它们之间的耦合度不高，各个团队可以独立工作，但某些功能仍会涉及多个子域，因此将它们视为一个整体域并相应地组织团队是合理的。

值得注意的是，值机与登机域和行程管理域中包含名称相同的子域，但根据事件风暴和其他会议的洞察，它们具有不同的语义和目的，分开建模可以避免增加耦合和复杂性。

确定了域和子域后，航空公司根据现代化每个子域的成本和收益进行基于价值的优先级排序。例如，预订域因其在业务流程中的关键地位而被选为现代化的第一阶段，现代化后系统的稳定性得到改善，在高用户流量时利润增加。同时，航空公司也认识到领域建模和现代化需要采用渐进式方法，因为在现代化过程中可能会发现旧系统中未被发现的功能和边缘情况。

6. 事件风暴识别域和子域

在识别域和子域时，有多种技术可供选择，而事件风暴是一个很好的起点。它允许不同人员参与，并能揭示与识别域和子域相关的重要信息。不同类型的事件风暴相辅相成，大图景事件风暴适合识别更高级别的模糊边界，流程建模和软件设计事件风暴则适合深入细节，增强对提议的领域边界的信心。

7. 关键事件识别

在将事件风暴划分为域和子域之前，识别关键事件是一个很好的准备步骤。关键事件是最重要的领域事件，能为理想的边界位置提供线索。它们不是领域边界，而是一种探索可能存在领域边界区域的方法。

确定关键事件是主观的，不同领域和人员的标准可能不同。但这并不是大问题，关键事件在研讨会后不需要正式记录或文档化，它们只是识别边界的垫脚石。简单地让人们识别最重要的事件可以引发有价值的讨论，揭示如何塑造边界的线索。如果需要更多指导，可以将任务细化为 “领域中的关键过渡点或里程碑是什么，例如潜在客户何时成为客户？”

以金融机构的会员申请流程为例，“申请会员” 是一个关键事件。非会员安装应用程序并提供个人和银行信息后可以申请会员。申请会员后，欺诈检查器需要进行安全检查，账户经理需要进行入职评估。这个关键事件之所以有用且是领域边界的指示器，原因如下：
- 产品负责人认为 “申请会员” 是最重要的事件之一，因为产品严重依赖网络效应，每月的申请数量与收入有很强的相关性。这使团队成员对重要事项达成共识。
- 事件前后对客户的描述不同，之前是非会员，之后是申请人。
- 该事件触发了两个新流程，并将活动交接给两个新角色。
- 事件前后的领域角色不同，之前是构建申请请求的规范，之后是执行规范所支持的流程。

graph LR
    A[非会员安装应用] --> B[提供个人和银行信息]
    B --> C[申请会员]
    C --> D[欺诈检查器进行安全检查]
    C --> E[账户经理进行入职评估]

有时，在高级研讨会中，团队可能难以限制关键事件的数量，因为大部分业务活动可能仅由少数事件覆盖，导致许多事件都可能被视为关键事件。为了在这类高级研讨会中有效使用关键事件，建议如下：
- 细化任务，明确询问关键过渡点或里程碑。
- 引导团队关注事件对业务的重要性和影响。

软件领域划分与事件风暴应用指南

8. 关键事件数量限制问题

9. 关键事件在不同场景的应用差异

10. 事件风暴与其他技术的结合

虽然事件风暴是识别域和子域的有效方法，但结合其他技术可以进一步提高识别的准确性和效率。以下是一些可以结合使用的技术及其优势：
- 领域驱动设计（DDD） ：事件风暴可以为 DDD 提供丰富的领域知识和事件信息，帮助确定实体、值对象和聚合根等概念。而 DDD 的分层架构和设计原则可以指导事件风暴中识别的域和子域进行更合理的架构设计。
- 数据建模 ：通过分析事件风暴中涉及的数据流动和数据关系，可以结合数据建模技术构建更准确的数据模型。数据模型可以为域和子域的划分提供数据层面的支持，确保数据的一致性和完整性。
- 流程挖掘 ：流程挖掘可以从实际的业务流程数据中发现潜在的流程模式和关键节点。将流程挖掘的结果与事件风暴相结合，可以更全面地了解业务流程，准确识别域和子域的边界。

11. 子域分组的实施步骤

在实际应用中，将子域分组到不同的域中需要遵循一定的步骤，以确保分组的合理性和有效性。以下是具体的实施步骤：

graph LR
    A[收集子域信息] --> B[分析子域关系]
    B --> C[选择分组启发式方法]
    C --> D[进行初步分组]
    D --> E[评估分组效果]
    E --> F{是否满意}
    F -- 是 --> G[确定分组方案]
    F -- 否 --> B

收集子域信息 ：通过各种方式，如事件风暴、业务调研等，收集所有子域的详细信息，包括功能、业务流程、数据等。
分析子域关系 ：研究子域之间的依赖关系、交互频率、业务相关性等，找出具有密切关系的子域。
选择分组启发式方法 ：根据业务需求和目标，选择合适的分组启发式方法，如产品或服务聚焦域、水平域等。
进行初步分组 ：按照选择的启发式方法，将子域进行初步分组。
评估分组效果 ：从耦合度、内聚性、业务价值等方面评估分组的效果，检查是否达到预期目标。
确定分组方案 ：如果评估结果满意，则确定最终的分组方案；如果不满意，则返回分析子域关系步骤，重新进行分组。

12. 领域划分的持续优化

领域和子域的划分不是一次性的工作，而是需要持续优化的过程。随着业务的发展和变化，原有的领域划分可能不再适应新的需求，需要及时进行调整。以下是持续优化的建议：
- 定期评估 ：定期对领域和子域的划分进行评估，检查是否存在耦合度过高、内聚性不足等问题。
- 关注业务变化 ：密切关注业务的发展动态，如新产品推出、业务流程调整等，及时调整领域划分以适应变化。
- 收集反馈 ：收集团队成员、业务用户等的反馈意见，了解他们在实际工作中对领域划分的感受和建议。
- 持续学习和改进 ：不断学习新的领域划分技术和方法，借鉴其他企业的成功经验，持续改进领域划分的质量。

13. 总结

识别域和子域是软件架构设计中的重要环节，事件风暴是一种有效的识别方法。通过识别关键事件、合理分组子域以及结合其他技术，可以更准确地划分域和子域，为软件系统的现代化和优化提供有力支持。同时，领域划分需要持续优化，以适应业务的不断变化。在实际应用中，应根据具体情况选择合适的方法和技术，灵活运用各种启发式方法，确保领域划分能够满足业务需求，提高软件系统的性能和可维护性。