如何设计一个复杂的业务系统

一、设计要干啥

作为一个企业级应用架构，自然会把专注点转移到业务应用功能性设计本身上来。现在来说对于一个复杂业务架构进行设计，我们要想做到又快又好，无非是两种情况：一是架构师本身对业务理解很深、能力超强、炉火纯青；二是原有的业务系统本身模型清晰，足够的“高内聚低耦合”，可以快速在其基础之上分析业务变化形成新的业务架构设计。

为什么我们要在代码实现前做设计？软件架构设计的实质是通过核心问题的分离降低复杂度，并让系统能够更快地响应外界业务的变化，并且使得系统能够持续演进。在遇到变化时不需要从头开始，保证实现成本得到有效控制。

从架构设计角度，以下三点是最为关键的：

让我们的模型、组件和业务划分尽量靠近变化的本质，比如对于一般电商系统来说，就是用户、商品、交易、支付等，这样的划分能够让我们将变化“隔离”在一定的范围(业务模块)内，从而帮助我们有效减少改变点。
设计上，业务模型内部是高内聚，模型之间是低耦合，即各自完成的业务是相对独立的，不会因为一方掉线而牵连另外一方，比如商品推荐功能挂掉了，但是交易和支付业务应该继续正常提供服务，可能提示用户暂时无法提供推荐服务，或者干脆降级为兜底策略。
模型、组件在业务上尽可能是复用的，正是这样的复用才成就了今天的互联网级架构，我们不会每做一个电商系统都从零做起。而被“复用”最多的业务模块显然会重点设计和运营，成为核心业务模块。当然架构上这样的电商系统必然也会比较健壮。

二、设计怎么做

业务软件开发的常见病：从一个小的项目不断开发演化变成一个大型业务系统，但随着新需求的不断增加，最终演变成了开发团队的噩梦。而这些噩梦大部分是源于软件的概念完整性（“概念完整性”一词来源于软件工程的经典著作《人月神话》）遭到了破坏。这些业务代码可能是一代又一代的开发人员各行其道的堆叠起来的（我们又称之为“屎山”），而这个过程中没人有意识的去维护软件的概念完整性。而 DDD 领域设计，特别是 DDD 提供的战略建模层面的概念，是维护软件概念完整性的良药。

“技术服务于业务、业务驱动技术”是目前大部分人的共识，尤其是对商业公司而言。而 DDD 领域设计主张在软件设计中把业务领域本身作为关注的焦点（换句话说就是软件开发人员要懂业务）非常符合这种思想；并且，DDD 提供了切实可行的面对复杂业务软件设计的解决方法，这也是我非常提倡作为一个架构师去深入学习和讨论 DDD 领域设计的相关知识。

2.1战略建模

在战略层面，DDD 非常强调对业务问题的分析和分解，通过识别核心问题来降低问题的复杂度。DDD 在战略层面维护模型的概念完整性的方法，最重要的两个概念就是界限上下文（Bounded Context）和防腐层（Anti-Corruption Layer）。

定义好界限上下文

关于界限上下文的定义，随便一本讲 DDD 的书上都会详细讲解，这里我只想分享一下自己的一些理解。这时，有人会问：界限上下文多大才能合适呢，划分上下文有没有可以遵循的规则呢？

划分上下文的规则，无非就是放之四海而皆准的“高内聚、低耦合”，这么说可能还是太虚。其实真正让大家感到纠结的是，不知如何切分的那些东西之间所存在的关联，有的甚至干脆都纳入到一个上下文里。其实，我认为与其关注上下文的“大小”，不如关注模型的“质量”，关注概念的完整性是不是容易被破坏。我觉得，判断大小是不是合适，要结合应用开发团队的能力，看开发团队能在多大的一个范围内掌控软件的概念完整性。只要是开发团队没有问题，这个范围就算再大也都是可以的。

如果开发团队的水平在业界属于上游，那么维护上下文的范围往往是很大的；一些公司开发团队的水平参差不齐，所以在项目的实施过程中，可能需要划分相对小的上下文，尽可能减少“屎山”的不断堆积。

做好防腐层

界限上下文需要时刻保护好自己所维护的边界，以及边界内概念的完整性，这时需要将某个上下文的概念转化为另一个上下文概念的地方就叫做“防腐层”。防腐层的实现有很多种，典型的比如作为适配器 Adaptor 来实现，另外广义上讲，Gateway 也是一个典型性的防腐层组件，当然，防腐层的代码和其他内部业务模型之间要存在明显的物理边界（当然不一定说要把防腐层作为一个个独立部署的进程），至少我们可以考虑把防腐层作为一个独立的类库来进行构建和维护，阿里内部的比如星环、其实就是这个思路。

2.2 战术建模

DDD 在战术上最核心的概念就是实体和聚合，为了更好的理解什么是聚合、聚合根、聚合内部实体，下面举例说明一下。想象一下一个电商系统的订单相关的模型，我们可能会得到订单 Order、订单头 OrderHeader、订单行项 OrderItem 三个相互关联的概念：

一个叫做 Order 的聚合。
这个订单聚合的聚合根是一个叫做 OrderHeader 的实体，实体 OrderHeader 的 ID 叫做 OrderId（订单号）。
通过 OrderHeader 实体，我们可以访问 OrderItem 实体的一个聚合。OrderItem 这个实体的局部 ID 叫做 ProductId（产品 ID）。因为业务善变不允许在同一个订单的不同订单项内出现同一个产品，所以我们可以选择产品 ID 作为订单项的局部 ID。

“聚合是数据修改的单元”，基于这个原则，我们可以做到“聚合内强一致、聚合外最终一致”，比如，我们可以不能接受一个订单内的所有订单项的金额之和不等于订单头的总金额，我们就必须把订单头和订单行项这两个实体划分到同一个聚合内。

设计聚合的原则

我们不妨先看一下《实现领域驱动设计》一书中对聚合设计原则的描述，原文是有点不太好理解的，我来稍微解释一下：

在一致性边界内建模真正的不变条件。聚合用来封装真正的不变性，而不是简单地将对象组合在一起。聚合内有一套不变的业务规则，各实体和值对象按照统一的业务规则运行，实现对象数据的一致性，边界之外的任何东西都与该聚合无关，这就是聚合能实现业务高内聚的原因。
尽量设计小的聚合。如果聚合设计得过大，聚合会因为包含过多的实体，导致实体之间的管理过于复杂，高频操作时会出现并发冲突或者数据库锁，最终导致系统可用性变差。而小聚合设计则可以降低由于业务过大导致聚合重构的可能性，让领域模型更能适应业务的变化。
通过唯一标识引用其它聚合。聚合之间是通过关联外部聚合根 ID 的方式引用，而不是直接对象引用的方式。外部聚合的对象放在聚合边界内管理，容易导致聚合的边界不清晰，也会增加聚合之间的耦合度。
在边界之外使用最终一致性。聚合内数据强一致性，而聚合之间数据最终一致性。在一次事务中，最多只能更改一个聚合的状态。如果一次业务操作涉及多个聚合状态的更改，应采用领域事件的方式异步修改相关的聚合，实现聚合之间的解耦（相关内容我会在领域事件部分详解）。
通过应用层实现跨聚合的服务调用。为实现微服务内聚合之间的解耦，以及未来以聚合为单位的微服务组合和拆分，应避免跨聚合的领域服务调用和跨聚合的数据库表关联。

上面的这些原则是 DDD 的一些通用的设计原则，还是那句话：“适合自己的才是最好的。”在系统设计过程时，你一定要考虑项目的具体情况，如果面临使用的便利性、高性能要求、技术能力缺失和全局事务管理等影响因素，这些原则也并不是不能突破的，总之一切以解决实际问题为出发点。

设计聚合的步骤

DDD 领域建模通常采用类似事件风暴，一般通过用例分析、场景分析和用户旅程分析等方法，通过头脑风暴列出所有可能的业务行为和事件，然后找出产生这些行为的领域对象，并梳理领域对象之间的关系，找出聚合根，找出与聚合根业务紧密关联的实体和值对象，再将聚合根、实体和值对象组合，构建聚合。

第一步：采用用例分析或事件风暴等方法，根据业务行为，梳理出在过程中发生这些行为的所有的实体和值对象，比如投保单、标的、客户、被保人等等。
第二步：从众多实体中选出适合作为对象管理者的根实体，也就是聚合根。判断一个实体是否是聚合根，上一章也说过，你可以结合以下场景分析：是否有独立的生命周期？是否有全局唯一 ID？是否可以创建或修改其它对象？是否有专门的模块来管这个实体。图中的聚合根分别是投保单和客户实体。
第三步：根据上一章说的设计聚合的原则，找出与聚合根关联的所有紧密依赖的实体和值对象。构建出一个包含一个聚合根、多个实体和值对象的对象集合，这个集合就是聚合。在图中我们构建了客户和投保这两个聚合。
第四步：在聚合内根据聚合根、实体和值对象的依赖关系，画出对象的引用和依赖模型。这里需要说明一下：投保人和被保人的数据，是通过关联客户 ID 从客户聚合中获取的，在投保聚合里它们是投保单的值对象，这些值对象的数据是客户的冗余数据，即使未来客户聚合的数据发生了变更，也不会影响投保单的值对象数据。从图中我们还可以看出实体之间的引用关系，比如在投保聚合里投保单聚合根引用了报价单实体，报价单实体则引用了报价规则子实体。
第五步：多个聚合根据业务语义和上下文一起划分到同一个限界上下文内。

那以上就是一个聚合诞生的完整过程了。

三、非功能需求

云原生在技术上能够最大程度的解决众多非功能性质量和技术需求

在云原生时代，我们需要将弹性作为首要考虑的因素，纳入建模的考量。那么弹性边界，就是我们划分系统的重要依据。而且，我们还需要考虑弹性边界间的依赖关系，尽量避免弹性耦合。对于业务建模来说，为了配合云原生时代的架构，我觉得要做到如下几点：

确立一种模型结构能够反映弹性边界，而这时候需要考虑不同弹性边界的原则来划分界限上下文；如果两个上下文明显具有不同的弹性诉求，那就应该拆分。而如果具有一致的弹性诉求，可以考虑先不拆。那这个时候拆分微服务到底能多“微”呢？简单说就是“微”到能够更好的利用弹性来控制成本的大小。
从异步模型的视角，去优化业务逻辑；典型就是 MQ 消息队列系统，由于有 broker，所以生产者和消费者不必在同一时间都保持可用性以及相同的吞吐量，而且生产者也不需要马上等到回复。
位置的松耦合：典型就是服务注册中心，消费端完全不需要直接知道提供端的具体位置，而都通过注册中心来查找服务来访问。
在弹性边界切分业务上下文时，同一个弹性边界内部维护业务强一致性。
在异步调用产生中间态异常时，需要维护业务最终一致性。

四、SOA、微服务、中台

多年前，这些传统的大型 ERP 业务软件，其实都是在一个很大的范围内维护业务概念的完整性。一个 ERP 安装完毕后，数据库有七八百张表（也就是七八百个实体）处于同一个界限上下文之内。但是这些 ERP 在这样一个巨大的界限上下文内仍然很好的维护了业务概念的完整性，实在令人敬佩。

然而实现它非常困难，但是破坏它却非常容易。一套 ERP 定制项目实施下来，数据库里可能又多了几百张表，更不用说不规范的命名看起来千奇百怪。这些厂商的 ERP 实施顾问和开发人员，夜以继日的维护这个庞大的“屎山”。我们不能让这些庞大的“单体应用”无限制的增长，于是我们又一次祭起了“分而治之”的大旗。想 SOA 这样的软件组件化技术给我们提供了拆分的工具。我们把一个大的界限上下文按照利于拆分成几个相对来说小一些的界限上下文；在物理上，我们把一个大的单体应用拆分成若干服务。

一般来说，我们会让服务的物理边界和界限上下文的领域边界基本堆砌，一个界限上下文对一个或多个可以独立部署的服务应用，服务应用包含了界限上下文的核心业务逻辑的实现。SOA 的服务组件的物理边界给服务间的调用增加了一些困难，这就使得开饭人员简化对象之间的关系，编写更加“高内聚、低耦合”的代码。当服务组件不多的时候，构建防腐层的工作量也不会很大，我们只要处理好组件之间的代码即成就好了。

但是，我们的架构师和开发人员太喜欢“分而治之”了，微服务的广泛使用甚至说是滥用，让我们看很多微服务真的是很“微”，几乎是一个 DDD 的聚合就可以对应一个可以独立部署的微服务。这样的微服务单单靠本身做不了太多的业务，这就需要更多更多的微服务“聚合”起来一起才能对外提供业务服务。

当然，微服务技术基础设施的发展也为服务之间的调用提供了更多的便利，跨越微服务的边界成为了常态；这个时候，业务开发人员区分“同一个上下文内的服务调用”和“上下文之间的防腐层”就要时刻保持头脑清醒，这时候的界限上下文和微服务的物理边界往往很难对齐，这就必然增加了维护每个界限上下文概念完整性的难度。

既然维护一个个“微小”的独立的界限上下文概念完整性越来愈难，那么我们干脆将它们再聚合起来吧？将它们融合到一个大小适度的界限上下文，那这就是所谓的企业级业务架构，也就是我们现在说的业务中台，最终目的可以说想要获得“企业级”的大和谐。

所以在一定程度上讲，软件工程就是妥协的艺术，是“中庸之道”。我们要不要中台，要大的中台，不管企业的大小，都应该结合自身的业务目标以及拥有的资源，在“维护更大范围的概念完整性”和“维护更多的防腐层代码”之间做出平衡，那这也是一个企业级架构师所要做的最核心的事情之一。

五、结语

做软件架构的其实很羡慕做建筑架构的，因为建筑架构有严谨的力学基础作为基座，有很多可以精确计算的东西，而软件架构却没有多少可以精确计算出来的成分，所以，前面说的“不断的妥协”不失是一种可行的设计思路和设计艺术；其实这也应验了那句“没有银弹”。