DDD助力平台能力复用

系统为何会变复杂

不确定性是互联网业务发展的主旋律，产品与业务每天都在迭代，研发团队需要面对这种不停的变化，应对这种变化最好的方式就是主动进化。

面对变化，研发团队需要有这样一个共识，需求是易变的，需求点是不精确的，代码是会腐化的，老板是想要多快好省的。

技术同学能做的就是，如何在以上这些点上做平衡取舍，当某一个或者某几个变量出现时，我的系统可以快速扩展应对和弹性应对。

背后还是分离术，哪些本质的东西是不变的，我们深挖它，哪些是易变的，我们想法屏蔽变更复杂度。

领域驱动方法论

谈到业务复杂度治理，最火的就是DDD了，通过DDD背后的治理方法论，可以有效的分离业务和技术复杂度，使得领域层代码和领域模型保持高度一致。

为实现这种一致，就要求所有需求的参与者（研发/产品/运营）对于这个业务的建模/模型/设计的理解是一致的，是有共识的，这样才能实现分析模型与设计模型不再割裂。

结合我个人经验，一个大型平台系统复杂度提升无外乎两个方面导致的：系统业务纬度与系统技术纬度。

所以在通过DDD做系统复杂度治理时，可以从这两个方向入手。

架构抽象来说是由元素及元素之间的关系组成的。

所以元素数量越多越复杂，比如代码规模，关系越乱越复杂，比如层级套用/递归等。

技术复杂度来源于系统对于稳定性的追求，比如代码质量/高可用/高性能/安全性/高病房/扩展性等。很多人在面对这些选项时无从下手，主要表现为，不知如何控制代码及系统复杂度，不知道如何让服务/模块具有扩展性和弹性，不知道是代理好还是直连好，数据层怎么做预热/异构/加工等。当一个复杂的核心链路上多个系统有不同的技术要求时，如何取舍做好架构就更懵逼了。

我解决不好我就不去解决就可以了，所以在DDD中首先的一个思想就是，剥离业务逻辑细节与技术实现细节。首先划定一个业务逻辑与技术逻辑的边界，从而隔离各自的复杂度。技术层的技术迭代不会影响业务，业务的扩展也不受技术的制约。

DDD里面体现这种剥离是由六边形架构实现的。

所以在DDD落地过程中，最重要的一点就是充分交流/提炼知识点/获取问题域/划定上下文边界/识别核心域与其他子域，这样一步步的将一个复杂的业务场景问题，拆成细粒度的，独立且内聚的子系统，实现目标聚焦，进而实现了复杂度可控。

除了六边形架构，在DDD中还有哪些可以直接借鉴的架构划分模式呢？

六边形架构

清晰界定技术边界与业务边界；

CQRS 分离了查询场景和命令场景，让同步与异步成为了可选，实现了低延迟与高并发的不同要求。

分层架构

将关注点以分层的形式剥离，不同的业务逻辑关注点放在不同的层里面。

战略设计与战术设计

DDD设计主要分为两个过程：战略设计与战术设计。

战略设计

一般是领域专家通过充分沟通，事件风暴或者场景分析，分析需求提炼知识点，得到清晰问题域，输出UL。

在基于UL继续进行问题域分析与建模，进而识别业务边界，确定限界上下文，之后根据限界上下文划分成不同的独立域。

在引入系统上下文实现系统与外部环境的衔接。

战术设计

战术设计是深入问题域，专注于一个领域的实现，依赖面向对象思想，专注聚焦于某个内聚的限界上下文中，对模型进行分解与建模。

领域驱动设计强调和突出了领域模型的重要性，通过整个领域驱动设计过程，绑定领域模型和技术模型，以保证领域模型和技术模型在贯穿整个软件开发的生命周期中（需求分析、建模、架构、设计、编码、测试与持续重构）的强一致性。领域模型指导着软件设计以及技术编码实现，接着通过重构实践来挖掘隐式概念，完善统一语言和模型，运用设计模式改进设计与开发质量。以下是领域驱动设计的粗略过程：

识别限界上下文

明确了系统的问题域和业务期望后，梳理出主要的业务流程，这些业务流程体现了各种参与者在这个过程中通过业务活动共同协作，最终完成具有业务价值的领域功能。

业务流程结合了参与角色（Who）、业务活动（What）和业务价值（Why）。

在业务流程的基础上，我们就可以抽象出不同的业务场景，这些业务场景又由多个业务活动组成，可以利用领域场景分析方法剖析场景，以帮助我们识别业务活动，例如采用用例对场景进行分析，此时，一个业务活动实则就是一个用例。业务流程是一个由多个用户角色参与的动态过程，而业务场景则是这些用户角色执行业务活动的静态上下文。

从不同角度看待限界上下文，限界上下文会呈现出对不同对象的控制力：

• 领域逻辑层面：限界上下文确定了领域模型的业务边界，维护了模型的完整性与一致性，从而降低系统的业务复杂度。

• 团队合作层面：限界上下文确定了团队的工作边界，建立了团队之间的合作模式，提升了团队间的协作效率，“康威定律”告诉我们，系统设计（产品结构）等同组织形式，每个设计系统的组织，其产生的设计等同于组织之间的沟通结构，限界上下文指导产生的团队结构的工作模式是最高效的。

• 技术架构层面：限界上下文确定了系统架构的应用边界，保证了系统层和上下文领域层各自的一致性，建立了上下文之间的集成方式。微服务中，限界上下文指导技术人员划分微服务的边界，通常一个限界上下文作为一个在独立进程中运行的微服务。

与中台关系

利用 DDD 提倡的分层、六边形等架构，分离了业务复杂度和技术复杂度，使得系统具备更强的扩展性和弹性；战术层面提供了元模型（聚合，实体，值对象，服务，工厂，仓储）帮助构建清晰、稳定，能快速响应变化和新需求能力的应用；

DDD 构建的应用能快速方便地切到微服务；领域驱动设计给企业应用带来的稳定性、灵活性、扩展性和应对变化的响应力对于建立灵活前台、稳固中台能带来巨大的帮助作用。

分治思想搭建技术框架

我们架构上的经验，遇到复杂问题是最好的方式就是分治，可以将现有平台系统拆成两部分：

• SDK：前端SDK负责实现开放能力

• 数据源服务：后端数据源&服务

• 流程画布：灵活强大的流程画布

• 移植部署流程：快速移植和部署到任何三方IT环境的方案能力

这样的分发其实适用于很多平台型系统的技术框架，通过这种分治可以实现业务复杂度控制，同时具备极强的扩展性和弹性。