作者：焦方飞
大年初一，看完中国队 1:3 越南队的比赛，在思考中国足球每况愈下的深层次原因之外，不禁回想起这几年做过的一些大型企业数字化转型项目，有得有失，最终回归到本源“如何设计和实施一个复杂软件工程”这个问题上，趁着春节长假，把自己的一些对架构设计思考和学习随笔写下来，写的仓促，希望能引起大家一些启发和讨论。当然本文所说的软件开发主要业务应用软件的开发，而中间件、数据库等技术组件开发的关注点则在其他一些方面，不在这里展开。
如何解决复杂业务设计
软件架构设计本身就是一个复杂的事情，但其实业界已有一个共识，那就是“通过组件化完成关注点的分离从而降低局部复杂度”。其实现在我们用的无论是容器、中间件、消息、数据库等，在某种意义上都是组件化的产物。这样的好处是在不同的系统里可以复用。在云原生兴起的今天，以通用的、组件化的服务形式更容易为我们所用，所以说现在如果还不享用云原生技术红利，那你就会被时代抛弃。
云原生满足非功能性质量需求
云原生在技术上能够最大程度的解决众多非功能性质量和技术需求（如上图），那作为一个企业级应用架构，自然会把专注点转移到业务应用功能性设计本身上来。现在来说对于一个复杂业务架构进行设计，我们要想做到又快又好，无非是两种情况：一是架构师本身对业务理解很深、能力超强、炉火纯青；二是原有的业务系统本身模型清晰，足够的“高内聚低耦合”，可以快速在其基础之上分析业务变化形成新的业务架构设计。我们应该追求的是第二种情况，这也就意味着从一开始的企业级模型建设，就要对模型设计、业务流程仔细对待，只有做到基础扎实，才能有后面的“快速迭代”。
我们再回到架构设计的本质，即为什么我们要在代码实现前做设计。设计首先是要解决问题的复杂度。于是有人做了一个架构，交给了一个团队去实现，很快发现实现的架构和设计完全是两回事。当然原因很明确——缺少了交流和沟通；其次是要建立团队协作沟通的共识。即使我们做好了一个团队都达成共识的架构设计，大家都兢兢业业把设计变成了现实，一个长期困扰软件行业的问题出现了，需求总是在变化，无论预先设计如何“精确”，总是发现下一个坑就在不远处，结果往往是情况越来越糟糕，也就是我们常说的架构“腐化”了，最后大家不得不接受重写。这些经历让我们逐步明确了软件架构设计的实质是通过核心问题的分离降低复杂度，并让系统能够更快地响应外界业务的变化，并且使得系统能够持续演进。在遇到变化时不需要从头开始，保证实现成本得到有效控制。
所以，我觉得从架构设计角度，以下三点是最为关键的：
- 让我们的模型、组件和业务划分尽量靠近变化的本质，比如对于一般电商系统来说，就是用户、商品、交易、支付等，这样的划分能够让我们将变化“隔离”在一定的范围(业务模块)内，从而帮助我们有效减少改变点。
- 设计上，业务模型内部是高内聚，模型之间是低耦合，即各自完成的业务是相对独立的，不会因为一方掉线而牵连另外一方，比如商品推荐功能挂掉了，但是交易和支付业务应该继续正常提供服务，可能提示用户暂时无法提供推荐服务，或者干脆降级为兜底策略。
- 模型、组件在业务上尽可能是复用的，正是这样的复用才成就了今天的互联网级架构，我们不会每做一个电商系统都从零做起。而被“复用”最多的业务模块显然会重点设计和运营，成为核心业务模块。当然架构上这样的电商系统必然也会比较健壮。
上面的三点毫无疑问都指向了业务，从业务出发、面向业务变化是我们现代架构设计成功的关键，所以说复杂业务架构设计的核心实质是保证面对业务变化时我们能够有足够快的响应能力。
领域设计
前面说了业务软件开发的常见病：从一个小的项目不断开发演化变成一个大型业务系统，但随着新需求的不断增加，最终演变成了开发团队的噩梦。而这些噩梦大部分是源于软件的概念完整性（“概念完整性”一词来源于软件工程的经典著作《人月神话》）遭到了破坏。这些业务代码可能是一代又一代的开发人员各行其道的堆叠起来的（我们又称之为“屎山”），而这个过程中没人有意识的去维护软件的概念完整性。而 DDD 领域设计，特别是 DDD 提供的战略建模层面的概念，是维护软件概念完整性的良药。
“技术服务于业务、业务驱动技术”是目前大部分人的共识，尤其是对商业公司而言。而 DDD 领域设计主张在软件设计中把业务领域本身作为关注的焦点（换句话说就是软件开发人员要懂业务）非常符合这种思想；并且，DDD 提供了切实可行的面对复杂业务软件设计的解决方法，这也是我非常提倡作为一个架构师去深入学习和讨论 DDD 领域设计的相关知识。
战略建模
在战略层面，DDD 非常强调对业务问题的分析和分解，通过识别核心问题来降低问题的复杂度。DDD 在战略层面维护模型的概念完整性的方法，最重要的两个概念就是界限上下文（Bounded Context）和防腐层（Anti-Corruption Layer）。
- 定义好界限上下文
关于界限上下文的定义，随便一本讲 DDD 的书上都会详细讲解，这里我只想分享一下自己的一些理解。这时，有人会问：界限上下文多大才能合适呢，划分上下文有没有可以遵循的规则呢？
划分上下文的规则，无非就是放之四海而皆准的“高内聚、低耦合”，这么说可能还是太虚。其实真正让大家感到纠结的是，不知如何切分的那些东西之间所存在的关联，有的甚至干脆都纳入到一个上下文里。其实，我认为与其关注上下文的“大小”，不如关注模型的“质量”，关注概念的完整性是不是容易被破坏。我觉得，判断大小是不是合适，要结合应用开发团队的能力，看开发团队能在多大的一个范围内掌控软件的概念完整性。只要是开发团队没有问题，这个范围就算再大也都是可以的。
如果开发团队的水平在业界属于上游，那么维护上下文的范围往往是很大的；一些公司开发团队的水平参差不齐，所以在项目的实施过程中，可能需要划分相对小的上下文，尽可能减少“屎山”的不断堆积。
- 做好防腐层
界限上下文需要时刻保护好自己所维护的边界，以及边界内概念的完整性，这时需要将某个上下文的概念转化为另一个上下文概念的地方就叫做“防腐层”。防腐层的实现有很多种，典型的比如作为适配器 Adaptor 来实现，另外广义上讲，Gateway 也是一个典型性的防腐层组件，当然，防腐层的代码和其他内部业务模型之间要存在明显的物理边界（当然不一定说要把防腐层作为一个个独立部署的进程），至少我们可以考虑把防腐层作为一个独立的类库来进行构建和维护，阿里内部的比如星环、其实就是这个思路。
一个典型的防腐层的设计
战术建模
DDD 在战术上最核心的概念就是实体和聚合，为了更好的理解什么是聚合、聚合根、聚合内部实体，下面举例说明一下。想象一下一个电商系统的订单相关的模型，我们可能会得到订单 Order、订单头 OrderHeader、订单行项 OrderItem 三个相互关联的概念：
- 一个叫做 Order 的聚合。
- 这个订单聚合的聚合根是一个叫做 OrderHeader 的实体，实体 OrderHeader 的 ID 叫做 OrderId（订单号）。
- 通过 OrderHeader 实体，我们可以访问 OrderItem 实体的一个聚合。OrderItem 这个实体的局部 ID 叫做 ProductId（产品 ID）。因为业务善变不允许在同一个订单的不同订单项内出现同一个产品，所以我们可以选择产品 ID 作为订单项的局部 ID。
“聚合是数据修改的单元”，基于这个原则，我们可以做到“聚合内强一致、聚合外最终一致”，比如，我们可以不能接受一个订单内的所有订单项的金额之和不等于订单头的总金额，我们就必须把订单头和订单行项这两个实体划分到同一个聚合内。
- 设计聚合的原则
我们不妨先看一下《实现领域驱动设计》一书中对聚合设计原则的描述，原文是有点不太好理解的，我来稍微解释一下：
- 在一致性边界内建模真正的不变条件。聚合用来封装真正的不变性，而不是简单地将对象组合在一起。聚合内有一套不变的业务规则，各实体和值对象按照统一的业务规则运行，实现对象数据的一致性，边界之外的任何东西都与该聚合无关，这就是聚合能实现业务高内聚的原因。
- 尽量设计小的聚合。如果聚合设计得过大，聚合会因为包含过多的实体，导致实体之间的管理过于复杂，高频操作时会出现并发冲突或者数据库锁，最终导致系统可用性变差。而小聚合设计则可以降低由于业务过大导致聚合重构的可能性，让领域模型更能适应业务的变化。
- 通过唯一标识引用其它聚合。聚合之间是通过关联外部聚合根 ID 的方式引用，而不是直接对象引用的方式。外部聚合的对象放在聚合边界内管理，容易导致聚合的边界不清晰，也会增加聚合之间的耦合度。
- 在边界之外使用最终一致性。聚合内数据强一致性，而聚合之间数据最终一致性。在一次事务中，最多只能更改一个聚合的状态。如果一次业务操作涉及多个聚合状态的更改，应采用领域事件的方式异步修改相关的聚合，实现聚合之间的解耦（相关内容我会在领域事件部分详解）。
- 通过应用层实现跨聚合的服务调用。为实现微服务内聚合之间的解耦，以及未来以聚合为单位的微服务组合和拆分，应避免跨聚合的领域服务调用和跨聚合的数据库表关联。
上面的这些原则是 DDD 的一些通用的设计原则，还是那句话：“适合自己的才是最好的。”在系统设计过程时，你一定要考虑项目的具体情况，如果面临使用的便利性、高性能要求、技术能力缺失和全局事务管理等影响因素，这些原则也并不是不能突破的，总之一切以解决实际问题为出发点。
- 设计聚合的步骤
DDD 领域建模通常采用类似事件风暴，一般通过用例分析、场景分析和用户旅程分析等方法，通过头脑风暴列出所有可能的业务行为和事件，然后找出产生这些行为的领域对象，并梳理领域对象之间的关系，找出聚合根，找出与聚合根业务紧密关联的实体和值对象，再将聚合根、实体和值对象组合，构建聚合。
电商系统大家都比较熟悉了，而且关于电商业务来说有许多比较成熟的模型可以直接借鉴；那下面我们以另外一个场景-保险投保业务为例，看一下聚合的构建过程主要都包括哪些步骤，当然这个例子我是从其他的学习资料里看到的，比较典型，可以当作示例来进行说明：
保险投保业务简单示例（From 学习资料）
- 第一步：采用用例分析或事件风暴等方法，根据业务行为，梳理出在过程中发生这些行为的所有的实体和值对象，比如投保单、标的、客户、被保人等等。
- 第二步：从众多实体中选出适合作为对象管理者的根实体，也就是聚合根。判断一个实体是否是聚合根，上一章也说过，你可以结合以下场景分析：是否有独立的生命周期？是否有全局唯一 ID？是否可以创建或修改其它对象？是否有专门的模块来管这个实体。图中的聚合根分别是投保单和客户实体。
- 第三步：根据上一章说的设计聚合的原则，找出与聚合根关联的所有紧密依赖的实体和值对象。构建出一个包含一个聚合根、多个实体和值对象的对象集合，这个集合就是聚合。在图中我们构建了客户和投保这两个聚合。
- 第四步：在聚合内根据聚合根、实体和值对象的依赖关系，画出对象的引用和依赖模型。这里需要说明一下：投保人和被保人的数据，是通过关联客户 ID 从客户聚合中获取的，在投保聚合里它们是投保单的值对象，这些值对象的数据是客户的冗余数据，即使未来客户聚合的数据发生了变更，也不会影响投保单的值对象数据。从图中我们还可以看出实体之间的引用关系，比如在投保聚合里投保单聚合根引用了报价单实体，报价单实体则引用了报价规则子实体。
- 第五步：多个聚合根据业务语义和上下文一起划分到同一个限界上下文内。
那以上就是一个聚合诞生的完整过程了。
不同场景下的领域建模策略
由于企业内情况千差万别，发展历程也不一样，有遗留单体系统的微服务改造，也有全新未知领域的业务建模和系统设计，还有遗留系统局部优化的情况。不同场景下，领域建模的策略也会有差异。下面我们就分几类场景来看看如何进行领域建模。
新建系统
新建系统对于复杂的业务领域，领域可能需要多级拆分后才能开始领域建模。领域拆分为子域，甚至子域还需要进一步拆分。比如：保险它需要拆分为承保、理赔、收付费和再保等子域，承保子域再拆分为投保、保单管理等子子域。复杂领域如果不做进一步细分，由于问题域太大，领域建模的工程量会非常浩大。你不太容易通过事件风暴，完成一个很大的领域建模，即使勉强完成，效果也不一定好。
对于复杂领域，我们可以分三步来完成领域建模和微服务设计。
- 拆分子域建立领域模型，根据业务领域的特点，参考流程节点边界或功能聚合模块等边界因素。结合领域专家和项目团队的讨论，将领域逐级分解为大小合适的子域，针对子域采用事件风暴，划分聚合和限界上下文，初步确定子域内的领域模型。
- 领域模型微调梳理领域内所有子域的领域模型，对各子域领域模型进行微调。微调的过程重点考虑不同领域模型中聚合的重组。同步考虑领域模型和聚合的边界，服务以及事件之间的依赖关系，确定最终的领域模型。
- 微服务的设计和拆分根据领域模型和微服务拆分原则，完成微服务的拆分和设计。
单体遗留系统
如果我们面对的是一个单体遗留系统，只需要将部分功能独立为微服务，而其余仍为单体，整体保持不变，比如将面临性能瓶颈的模块拆分为微服务。我们只需要将这一特定功能，理解为一个简单子领域，参考简单领域建模的方式就可以了。在微服务设计中，我们还要考虑新老系统之间服务和业务的兼容，必要时可引入防腐层。
云原生时代下的挑战
随着云原生技术的兴起，现在企业级架构就更加的云化，而云化的架构风格有了新的关注点：弹性边界。弹性边界是一个云原生企业级应用架构的核心概念，它指把弹性作为最优先的考虑要素而划定的系统边界，决定了我们是否能够充分发挥云原生平台的全部能力。于是我们就需要新的方法来弥补以前业务模型的不足，以满足新的云原生化的需要。现在可以说，微服务基本上就是以云原生架构作为基础，而在固定弹性的平台上使用微服务架构，有极高的实施成本。可以说，云原生实际上就应该是微服务的前置条件。
在云原生时代，我们需要将弹性作为首要考虑的因素，纳入建模的考量。那么弹性边界，就是我们划分系统的重要依据。而且，我们还需要考虑弹性边界间的依赖关系，尽量避免弹性耦合。对于业务建模来说，为了配合云原生时代的架构，我觉得要做到如下几点：
- 确立一种模型结构能够反映弹性边界，而这时候需要考虑不同弹性边界的原则来划分界限上下文；如果两个上下文明显具有不同的弹性诉求，那就应该拆分。而如果具有一致的弹性诉求，可以考虑先不拆。那这个时候拆分微服务到底能多“微”呢？简单说就是“微”到能够更好的利用弹性来控制成本的大小。
- 从异步模型的视角，去优化业务逻辑；典型就是 MQ 消息队列系统，由于有 broker，所以生产者和消费者不必在同一时间都保持可用性以及相同的吞吐量，而且生产者也不需要马上等到回复。
- 位置的松耦合：典型就是服务注册中心，消费端完全不需要直接知道提供端的具体位置，而都通过注册中心来查找服务来访问。
- 在弹性边界切分业务上下文时，同一个弹性边界内部维护业务强一致性。
- 在异步调用产生中间态异常时，需要维护业务最终一致性。
不要忽视组织结构的影响
“康威定律”告诉我们，组织结构会决定团队沟通的结构，也会决定产品的结构。对组织结构的梳理，在需求调研的时候会经常做。如果是信息收集而言，业务架构设计在这里并没有什么特殊之处。区别在于，业务架构的目标是企业级的能力规划，希望能够突破壁垒、形成合力。正是这个原因，组织结构对业务架构设计的反作用力也是很大的，企业级数字化转型方案要与组织结构相匹配，否则落地的时候会困难重重。可以说，部门利益是做企业级架构的最大障碍之一，跨越这个障碍也是对架构师的能力的要求之一。当然，有些情况下，没有更好的解决方案时，不动也是一种选择。
以我的经验，这种问题没有特别好的办法，无非是两种：一是有超强能力者主导，在最高层的支持下，强力推进这种决策，但是企业越大，尤其是以业务为主导地位的企业中，这种结构就愈难形成；二是加强企业内部的业务架构人员的能力和数量（最好各个部门都有类似的角色），让这些企业机构人员以合作伙伴的方式全程参与到项目中，在项目的实施过程中搭建起协作网络，提升决策效率，才能使组织结构不再是企业数字化转型的瓶颈。
SOA-微服务-中台：妥协的艺术
多年前，这些传统的大型 ERP 业务软件，其实都是在一个很大的范围内维护业务概念的完整性。一个 ERP 安装完毕后，数据库有七八百张表（也就是七八百个实体）处于同一个界限上下文之内。但是这些 ERP 在这样一个巨大的界限上下文内仍然很好的维护了业务概念的完整性，实在令人敬佩。
然而实现它非常困难，但是破坏它却非常容易。一套 ERP 定制项目实施下来，数据库里可能又多了几百张表，更不用说不规范的命名看起来千奇百怪。这些厂商的 ERP 实施顾问和开发人员，夜以继日的维护这个庞大的“屎山”。我们不能让这些庞大的“单体应用”无限制的增长，于是我们又一次祭起了“分而治之”的大旗。想 SOA 这样的软件组件化技术给我们提供了拆分的工具。我们把一个大的界限上下文按照利于拆分成几个相对来说小一些的界限上下文；在物理上，我们把一个大的单体应用拆分成若干服务。
一般来说，我们会让服务的物理边界和界限上下文的领域边界基本堆砌，一个界限上下文对一个或多个可以独立部署的服务应用，服务应用包含了界限上下文的核心业务逻辑的实现。SOA 的服务组件的物理边界给服务间的调用增加了一些困难，这就使得开发人员简化对象之间的关系，编写更加“高内聚、低耦合”的代码。当服务组件不多的时候，构建防腐层的工作量也不会很大，我们只要处理好组件之间的代码即成就好了。
但是，我们的架构师和开发人员太喜欢“分而治之”了，微服务的广泛使用甚至说是滥用，让我们看很多微服务真的是很“微”，几乎是一个 DDD 的聚合就可以对应一个可以独立部署的微服务。这样的微服务单单靠本身做不了太多的业务，这就需要更多更多的微服务“聚合”起来一起才能对外提供业务服务。
当然，微服务技术基础设施的发展也为服务之间的调用提供了更多的便利，跨越微服务的边界成为了常态；这个时候，业务开发人员区分“同一个上下文内的服务调用”和“上下文之间的防腐层”就要时刻保持头脑清醒，这时候的界限上下文和微服务的物理边界往往很难对齐，这就必然增加了维护每个界限上下文概念完整性的难度。
既然维护一个个“微小”的独立的界限上下文概念完整性越来愈难，那么我们干脆将它们再聚合起来吧？将它们融合到一个大小适度的界限上下文，那这就是所谓的企业级业务架构，也就是我们现在说的业务中台，最终目的可以说想要获得“企业级”的大和谐。
所以在一定程度上讲，软件工程就是妥协的艺术，是“中庸之道”。我们要不要中台，要大的中台，不管企业的大小，都应该结合自身的业务目标以及拥有的资源，在“维护更大范围的概念完整性”和“维护更多的防腐层代码”之间做出平衡，那这也是一个企业级架构师所要做的最核心的事情之一。
我们团队这些年确实做了一些“业务中台方法论”的积累和实践，并且在一些项目中做了实践，当然其中最灵魂的部分之一还是前面说的领域设计。以前很多人说 DDD 领域设计乃至业务中台方法论最难的就是没有一个合适的工具或者平台来实践，今天其实阿里开源的 COLA 以及内部使用的星环、BizWorks 都是很好的工具和平台。
结语
企业级应用架构是在不断的演进和迭代，但是我始终感觉企业应用架构的形成过程是在一种看起来科学的方法论下，但是又不完全科学的过程中实现的。仔细想一下，做软件架构的其实很羡慕做建筑架构的，因为建筑架构有严谨的力学基础作为基座，有很多可以精确计算的东西，而软件架构却没有多少可以精确计算出来的成分，所以，前面说的“不断的妥协”不失是一种可行的设计思路和设计艺术；其实这也应验了那句“没有银弹”。
由于时间仓促，有些内容简单带过，有些本应该结合实例来说明的地方在本文中也简略而过，后面有时间的话我会结合更多的实际案例来对本文说的观点进行补充。也希望本文能够激发大家一起对目前云原生时代的企业级应用架构设计的思考和讨论，相互学习，共同进步。