本文是上一篇《懂了这个道理，人月神话不再是神话！》的续篇，关注公众号（老肖想当外语大佬）获取以下信息：

1. 最新文章更新；

2. DDD框架源码（.NET、Java双平台）；

3. 加群畅聊，建模分析、技术交流；

4. 视频和直播在B站。

关注公众号一定要星标，以及时获得最新推送。

背景

在上一篇《关于领域驱动设计，大家都理解错了》中，我剖析了“复杂度”的概念。然而在与大家交流的过程中发现，很多软件设计决策的分歧来自对“复杂度”的理解不同。因此，我希望在这篇文章中全面地展示我对于“复杂度”的理解，以期与大家能够在更深的层次上识别共识，明晰分歧。

软件成本与复杂度

在设计软件系统时，我们始终面临一个约束条件，即“软件成本”，包括时间成本、人力成本等资源。我认为软件的“复杂度”是软件成本的核心因素。我坚信， 复杂度越高，软件成本越高 。因此，我所有的软件设计决策都构建在这个起点。如果我们期望 降低软件成本 ，就需要 降低软件的复杂度 。因此，理解复杂度是我们的必经之路。

理解复杂度

要理解复杂度，我们需要先回答一个问题：如何判断“复杂”和“简单”？举例来说，对比两个系统，你觉得哪个更复杂？显然，大部分人会选择“系统2”，因为它的 元素数量 更多。

如果系统元素之间存在一些关系，下面两个系统呢？是不是感觉“系统3”更复杂？

基于上述例子，我得出了两个判断：

1. 系统复杂度与 元素的数量 和 元素的关系 有关；

2. 元素的关系对系统复杂度的影响远远大于元素的数量所产生的影响。

基于上述观点，我们可以根据 元素数量 、 元素关系 这两个要素来衡量“复杂度”，也就是说我们可以有一个判断复杂度的标尺，这个标尺有两个重要参数： 元素数量 、 元素关系 。

我们知道， 不可衡量则不可改进 ，有了这个标尺，我们可以对决策方案的优劣取舍做判断，这就是我们能够持续改进的起点。

尊重复杂度

经典的复杂度守恒定律表示，“ 复杂度不可被消除，只可被转移 ”。在软件设计领域，我们的复杂度具体在哪里呢？我认为我们的软件系统复杂度的根源来自于需求本身的复杂度，它决定了最终解决方案复杂度。

既然复杂度无法被消除，我们可以推导得出，解决方案的复杂度最小等于需求的复杂度。因此，在设计方案的过程中，要尽可能 避免引入额外的复杂度 。这个过程中， 元素数量 和 元素关系 成为我们关注的要点，而 元素关系 是其中的重中之重。

在分析需求、给出解决方案的过程中，复杂度由两方面组成：业务逻辑本身的复杂度和引入的技术复杂度。业务逻辑来自需求，无法打折扣，因此这部分的复杂度是无法被消除的。这也就是为什么我所说的“ 尊重复杂度 ”，尊重业务固有复杂度，不要尝试消除它，我们能做的，仅仅是将它的复杂度尽可能封闭在一个个“收纳箱”里，这些收纳箱，就是我们常说的“领域”。

对于“技术复杂度”，我们要避免过度设计，避免引入额外的复杂技术，尽可能采取与需求匹配的技术解决方案。

如果你了解“熵”的概念，也许会发现，我们在讨论复杂度逻辑，与“熵增定律”不谋而合，而软件系统的复杂度也是随着我们一步步迭代走向更加复杂和混乱的，我们能做的就是尽可能维持复杂度的增速尽可能地低，使得系统复杂度尽可能在我们所能掌控的范围内。

因此，尊重复杂度，也是对自然规律的尊重。

掌控复杂度

在设计和实现软件系统的过程中，我们可以采取以下策略：

1. 尽可能避免引入元素关系；

2. 实在不行，用元素数量来置换元素关系，也是划算的；

这些策略在具体的软件系统建模中体现为：

1. 保持模型（聚合）之间的边界不被打破；

2. 如果一个需求现有模型无法满足，就考虑创建一个新的模型，而不是把原有的多个模型耦合在一起；

要掌控关系，我们需要具体到代码层面，识别什么是关系。我认为有下面特征的代码都属于关系：

1. 聚合类型之间的相互引用；

2. 一个类型，同时对多个聚合类型产生操作或影响；

基于上述认知，我们就得出一些代码原则：

1. 模型（聚合）之间不相互依赖；

2. 如果现有模型（聚合）无法满足需求，就创建一个新的模型（聚合）；

3. 模型之间的相互影响，通过“事件”传递信息，从而实现数据最终一致；

关于具体的代码怎么写，我在《DDD建模后写代码的正确姿势（Java、dotnet双平台）》一文中有一些示例展示，也欢迎大家参与我们DDD实战项目d3shop，一起体验掌控复杂度的实践，具体参见《欢迎加入d3shop，一个DDD实战项目》。

后续

本篇是从一个平面的视角来解析复杂度，探讨的是元素之间的关系对复杂度的影响。而一个复杂的系统，并不是简单的一层，在不同的层次，进行展开，又可以看作是一个子系统，下篇我们将从纵深的视角来剖析复杂度与领域驱动设计思想的相互关联。