复杂度定义

复杂系统是由大量相互作用的部分组成的系统。与整个系统比起来，这些组成部分相对简单，没有中央控制，组成部分之间也没有全局性的通信，并且组成部分的相互作用导致了复杂行为。

在软件系统中，函数、类、模块、组件和服务等都可以视为组成部分，他们之间的相互作用最终导致了软件系统的复杂行为。

复杂度成因分析

下面通过如下示例来更直观的感受下理解能力和预测能力两个维度对复杂度的描述：

• 内衣：原理简单，功能单一
• 手表：结构复杂，功能明确可预测
• 三人团队：需要通过简单的沟通和协作，做到团队成员间的角色和职责清晰可控
• 城市：城市建设的空间结构、人员结构都比较复杂，需要人花较多时间才能熟悉，城市的规划也随时间存在不确定性风险，比较难以预测结果
• 双摆：结构简单，但是对初始设置具有高度敏感性，其行为不可预测
• 股市：影响因素多且复杂，不可控，不可预测，是个典型的混沌模型

软件系统的复杂度分析

软件系统属于“复杂难解”+“复杂难测”，跟城市建设属于同一复杂度。下面从理解能力和预测能力两方面对软件系统的复杂度进行分析。

理解能力

规模分析

系统规模的扩张，不仅取决于需求的数量，还取决于需求功能点之间的关系，评估软件系统规模的元素包括但不限于以下几个

• 代码行数
• 包、类、方法的数量
• 继承的层次
• 方法的调用数
• 圈复杂度

开发过程中有很多的问题会导致软件系统规模的无序扩张，比较典型的有下面几个，资深程序员应该都遇到过

• 函数存在副作用。调用时可能对函数的结果做了隐含的假设
• 类的职责繁多，导致开发人员不敢轻易修改，因为不清楚其影响范围
• 热点代码被频繁变更，职责被包裹了一层又一层，没有清晰的业务边界
• 隐藏的 bug，在某些个不为人知的诱发条件具备时，就会让整个调用链路崩溃
• 不同业务场景的不同例外场景，其处理方式各不相同
• 同步与异步代码混合在一起，不可预知的调用链路顺序

结构分析

结构之所以变得复杂，多数情况下是由系统的质量属性决定的。软件系统从最初的单体系统到现在的分布式微服务体系，整个发展历程一直是不断拆分的微型化过程。软件系统的复杂同时也会加剧人员组织结构的复杂度。康威定律指出，任何组织在设计一套系统（广义概念上的系统）时，所交付的设计方案在结构上都与该组织的沟通结构保持一致。

无论是优雅的设计还是拙劣的设计都会给系统带来复杂度的增加，不同的是，优雅的设计是主动控制结构的复杂度，拙劣的设计带来的复杂度是偶发的，无序的，是技术债。

无序设计的几个典型表现：

• 代码没有显而易见的进入系统的入口
• 不存在一致性，不存在风格，也没有将不同的部分组织在一起的统一概念
• 系统中的控制流让人觉得不舒服，无法预测
• 系统中有太多“坏味道”
• 数据很少放在他被使用的地方，滥用缓存，视图让数据停留在更方便的地方

预测能力

影响预测能力的关键要素在于变化，而我们无法预知未来，也就无法预测未来可能发生的变化，这就带来了软件系统的不可预测性。对变化的应对不妥，就会导致软件系统的过度设计或设计不足。

过度设计的表现

• 引入不必要的抽象来保证产品的可扩展性

设计不足的表现

• 没有明确识别出未来确认会发生的变化，或者对需求变化发展的方向缺乏前瞻

如何控制软件复杂度

控制规模

领域驱动设计对软件复杂度的控制之道就是竭力改变设计的质量，然后在解空间中通过“分而治之”的方法将庞大的系统拆分为一个个小的软件元素来解决问题空间中的一个个细粒度的问题。拆分手段就是限界上下文和上下文映射，它们是战略设计阶段的核心。

清晰结构

为避免业务逻辑的复杂度与技术实现的复杂度混杂在一起，就需要确定业务逻辑与技术实现的边界，从而隔离各自的复杂度。这种隔离也符合关注点分离的设计原则。为此，领域驱动设计引入了分层架构，分层架构将业务逻辑封装到领域层，支撑业务逻辑的技术实现放到基础设施层，应用层既扮演了领域层的外观，又解决了业务逻辑跟技术实现的协作问题。

领域驱动设计通过限界上下文隔离了业务能力的边界，通过分层架构隔离了业务逻辑与技术实现，如此，保证了整个系统具有了清晰的结构，实现了有序设计。

响应变化

应对变化最好的方式就是将变化锁进笼子里，通过模式等抽象方法将不同维度、不同粒度的变化限定在一个可控的范围内，当变化来临时能及时感知，并作出最小的适应性改动。

通过领域建模可以将看似分散的事务抽象成一个统一的领域模型，将复杂的业务通过可视化的方式表达出来。当需求发生变化时，通过比对抽象出来的业务模型，即可敏锐的发现增量变化的部分，从而以最小的代价响应新增的需求。

本文内容为《解构领域驱动设计》（张逸 著）相关章节的读书摘要，略加修饰和解读，旨在加深理解，与君共勉