理解软件解决方案中的不同领域

# 理解软件解决方案中的不同领域 ## 1. 技术背景与需求 随着软件系统复杂度的提升，传统的软件开发方式面临诸多挑战，这促使了更复杂的持续集成/持续部署（CI/CD）周期的出现，以及复杂分布式架构的采用，如微服务和基于容器的架构。在这种情况下，实现复杂软件系统并搭配快速的 CI/CD 周期变得常见，这往往需要更多人员参与系统的演进和维护。因此，对于适用于高复杂度领域的技术以及多个松散耦合开发团队协作的需求应运而生。 ### 技术要求 - 需要安装 Visual Studio 2019 免费社区版或更高版本，并安装所有数据库工具。 - 相关代码片段可在 GitHub 仓库中找到。 ## 2. 软件领域的定义 在软件开发中，知识从领域专家向开发团队的传递至关重要。然而，在一个组织内，同一个词在不同部门可能有不同含义，相同的概念实体在不同上下文中也可能有不同形态。 ### 示例 以 WWTravelClub 为例，订单支付和套餐处理子系统对客户的定义完全不同： | 子系统 | 客户定义关注点 | 使用语言 | | ---- | ---- | ---- | | 订单支付 | 支付方式、货币、银行账户、信用卡 | 类似银行语言 | | 套餐处理 | 过往访问或购买的地点和套餐、用户偏好、地理位置 | 旅行社/运营商语言 | ### 传统解决方法 传统上，会使用一个名为“客户”的唯一抽象实体，将其投影为订单支付视图和套餐处理视图。系统设计师的主要任务是创建一个能解释所有视图的概念模型。 ### 传统方法的优缺点 - **优点**：能对领域数据进行唯一且连贯的表示，若概念模型构建成功，所有操作将有正式定义和目的，有助于组织流程的合理化。 - **缺点**： - **一致性问题**：随着系统复杂度增加，难以形成唯一连贯的数据视图。 - **更新困难**：频繁的系统变更需求使得维护全局模型变得困难，且局部变更的错误可能会传播到整个组织。 - **团队组织问题**：系统建模需分配给多个团队，强耦合任务需由同一团队处理。 - **并行性问题**：向微服务架构迁移时，单一数据库的瓶颈更加明显。 - **语言问题**：系统规模扩大后，需与更多使用不同语言和数据视图的领域专家沟通，增加了翻译成本。 - **效率问题**：处理大量字段的记录效率低下，尤其在对象关系映射（ORM）和业务层的更新操作中。 - **数据操作并行性问题**：数据存储子系统流量增加时，单一整体数据模型难以实现写操作的并行性。 ## 3. 领域驱动设计（DDD） ### 基本概念 DDD 旨在构建一个唯一的领域模型，将整个应用领域划分为多个小领域，每个领域有独立的模型，这些领域被称为有界上下文（Bounded Contexts）。每个领域由专家使用的语言定义，形成通用语言（Ubiquitous Language），开发团队和专家使用相同语言交流，无需翻译。 ### 处理有界上下文的方法 - **添加边界**：当语言术语含义发生变化时，添加有界上下文边界。例如，在 WWTravelClub 中，订单支付和套餐处理属于不同有界上下文。 - **明确关系**：不同开发团队需明确各自有界上下文与其他模型的关系，这些关系记录在共享文档中。 - **保持对齐**：通过组织会议和构建简化系统原型，确保所有有界上下文能够连贯演进，最终集成到所需的应用行为中。 ### 有界上下文间的通信 - **领域事件**：使用发布者/订阅者模式实现有界上下文间的通信，如在 WWTravelClub 中，购买事件触发后，订单支付有界上下文会创建支付操作。 - **语言翻译**：当事件或操作跨越有界上下文边界时，需立即将其翻译成接收上下文的通用语言，避免语言污染。 - **反腐败层**：当通信语言与目标通用语言差异较大时，在接收有界上下文边界添加反腐败层进行语言翻译。 ### 上下文映射 包含所有有界上下文及其相互关系和接口定义的文档称为上下文映射（Context Mapping），其中的关系规定了不同团队间的合作模式，常见模式如下： - **伙伴模式**：两个团队相互依赖，共同决定并在必要时更改有界上下文的通信规范。 - **客户/供应商模式**：一个团队作为客户，另一个作为供应商。双方定义客户侧有界上下文的接口和自动化验收测试，之后供应商可独立工作。例如，在订单支付和套餐处理上下文中，订单支付作为供应商，其功能从属于套餐处理的需求。 - **顺从模式**：客户侧接受供应商侧强加的接口，无协商阶段。这种模式通常在供应商的有界上下文是现有产品或遗留子系统，难以修改时使用。