如何设计一个复杂的业务系统？从对领域设计、云原生、微服务、中台的理解开始

简介：业级应用架构是在不断的演进和迭代，但是我始终感觉企业应用架构的形成过程是在一种看起来科学的方法论下，但是又不完全科学的过程中实现的。

作者：焦方飞

大年初一，看完中国队 1:3 越南队的比赛，在思考中国足球每况愈下的深层次原因之外，不禁回想起这几年做过的一些大型企业数字化转型项目，有得有失，最终回归到本源“如何设计和实施一个复杂软件工程”这个问题上，趁着春节长假，把自己的一些对架构设计思考和学习随笔写下来，写的仓促，希望能引起大家一些启发和讨论。当然本文所说的软件开发主要业务应用软件的开发，而中间件、数据库等技术组件开发的关注点则在其他一些方面，不在这里展开。

如何解决复杂业务设计

软件架构设计本身就是一个复杂的事情，但其实业界已有一个共识，那就是“通过组件化完成关注点的分离从而降低局部复杂度”。其实现在我们用的无论是容器、中间件、消息、数据库等，在某种意义上都是组件化的产物。这样的好处是在不同的系统里可以复用。在云原生兴起的今天，以通用的、组件化的服务形式更容易为我们所用，所以说现在如果还不享用云原生技术红利，那你就会被时代抛弃。

云原生满足非功能性质量需求

云原生在技术上能够最大程度的解决众多非功能性质量和技术需求（如上图），那作为一个企业级应用架构，自然会把专注点转移到业务应用功能性设计本身上来。现在来说对于一个复杂业务架构进行设计，我们要想做到又快又好，无非是两种情况：一是架构师本身对业务理解很深、能力超强、炉火纯青；二是原有的业务系统本身模型清晰，足够的“高内聚低耦合”，可以快速在其基础之上分析业务变化形成新的业务架构设计。我们应该追求的是第二种情况，这也就意味着从一开始的企业级模型建设，就要对模型设计、业务流程仔细对待，只有做到基础扎实，才能有后面的“快速迭代”。

我们再回到架构设计的本质，即为什么我们要在代码实现前做设计。设计首先是要解决问题的复杂度。于是有人做了一个架构，交给了一个团队去实现，很快发现实现的架构和设计完全是两回事。当然原因很明确——缺少了交流和沟通；其次是要建立团队协作沟通的共识。即使我们做好了一个团队都达成共识的架构设计，大家都兢兢业业把设计变成了现实，一个长期困扰软件行业的问题出现了，需求总是在变化，无论预先设计如何“精确”，总是发现下一个坑就在不远处，结果往往是情况越来越糟糕，也就是我们常说的架构“腐化”了，最后大家不得不接受重写。这些经历让我们逐步明确了软件架构设计的实质是通过核心问题的分离降低复杂度，并让系统能够更快地响应外界业务的变化，并且使得系统能够持续演进。在遇到变化时不需要从头开始，保证实现成本得到有效控制。

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

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

上面的三点毫无疑问都指向了业务，从业务出发、面向业务变化是我们现代架构设计成功的关键，所以说复杂业务架构设计的核心实质是保证面对业务变化时我们能够有足够快的响应能力。

领域设计

前面说了业务软件开发的常见病：从一个小的项目不断开发演化变成一个大型业务系统，但随着新需求的不断增加，最终演变成了开发团队的噩梦。而这些噩梦大部分是源于软件的概念完整性（“概念完整性”一词来源于软件工程的经典著作《人月神话》）遭到了破坏。这些业务代码可能是一代