大型网站应用架构师方案——浅谈分层、六边形、CQRS架构模式之架构的内核

• 1. 不谈项目包分层都是耍流氓

• 2. 读p8写出来的代码，我很失望

• 3. 架构的本质

• 4. 业界常用的架构模式

1. 不谈项目包分层都是耍流氓

在阿里我一些人分享过领域驱动设计，无论是分享中的表达还是工作中的交流，说的最多的就是：DDD不是项目包如何分层，不是去学习要建设哪些包，而是要知道DDD的思想和方法论，解决什么问题。

扯的蛋疼！每次跟我说这些我都觉得非常虚，缺失“土壤”，而大部分人还都听进去了，一直去回味理解这些方法论、思想。我在这里可以这么说，缺失“土壤”的思想和方法论都是“纸老虎”，一些高P的耍流氓手段。

2. 读p8写出来的代码，我很失望

DDD领域驱动设计的终极目标是更好地组织代码。

在DDD之前，我们就非常注重代码的扩展性和整洁性。就代码层次，下面是优秀代码的标准。

可读性强

借鉴马丁福勒的重构思想，对于一块业务，一般是直接翻译为一段不超过15行的代码块，而整个业务的流程都从这段代码读懂，而且不能有注释，即代码的业务意义层。而在阿里这个团队接触一段时间后，我所看到的代码，代码没有分层，该抽象的模块没有抽象，该使用设计模式的地方也不套用模式，代码混乱程度非常高，时时刻刻我都差点按捺不住着要重构的想法。

复用率高

代码中最常见的问题就是：散弹式修改（代码重复）。一个项目中，最低级的代码问题就是一段业务逻辑的代码在很多类里面都能看到，看到这种代码，基本上就能断定他的代码风格了：就是没有思想、没有设计理念、更没有计数追求。

那个阿里开发，犯了马丁福勒代码思想中提到的一个很严重问题：散弹式代码。 一个变化锚定了非常多的代码，而变化发生迭代，则需要找到所有的代码完成升级迭代。而我后来接手这块业务后，就迎来了迭代。而那段时间是非常痛苦的时期（几乎代码组织的各种问题他都犯了。），同时也是最爽的时期（能够重构这些代码了，本人有点代码洁癖）。

对于复用率高的代码，我们有很多手段来组织它，提炼类、提炼内部子类、模板方法、外加函数、本地扩展等等。

面向协议编码

上面两种模式是开发的基本功，而对于这一种“面向协议”模式，更是高阶用法。面向协议其实就是面向对象领域中的一种思考方式，对象的互联是基于协议的，大到系统之间，小到模块对象之间。

3. 架构的本质

无论是mvc三层架构，还是分层架构，六边形架构，洋葱架构。这些架构本质目标就一个：降本增效；消除依赖。

三层架构将展示层、业务层、数据访问层解耦了，每层都能独立演进、互不干涉，减少了生产过程中的沟通及生产成本。因此架构本质工作内容就是：消除依赖。

降本增效，在工业社会体现在分工上，分工明确，指定行业标准协议。各个分工互不干扰，相互协作提高生产效率、降低生产成本。在软件领域，分工就体现在软件的各个子模块之间的分工，各模块指定标准和协议。消除依赖，做到降本增效。而消除依赖就体现在系统的高内聚、低耦合特性上。

从概念定义的角度，高度内聚和松散耦合就如同硬币的两面，其中耦合这个概念衡量的是系统应对变化的灵活性；而内聚指的是组件（服务）实现自身功能需要的外部依赖，这两个概念的本质：任何软件系统只有高内聚，低耦合的情况下，才会表现出足够的稳定性。

那软件系统中有哪几类依赖(耦合)呢：代码实现依赖，时序性依赖，部署依赖，业务领域依赖。

代码实现依赖： 例如交易平台订单库表，对于下游的其他系统，需要读取订单的数据去支撑业务，如推荐系统。当订单表发生变更，而推荐系统又依赖订单表结构，那么这时候推荐系统就会宕机。这样的架构就是将一个变化锚定了系统的多处地方，解决这个问题，我们可以对订单的领域模型和数据模型进行”封装“，具体来说就是通过暴露”数据接口“，来驱动推荐服务通过API访问订单的数据。我们通常称呼这个模式为CQRS。这只是一个简陋的实现，对于更标准的方式是建立一个订单外部数据源，简称outbox模式(邮箱领域用法)。

时序性依赖： 订单中心在用户下单的时候，需要依次调用营销中心和用户中心，因此我们说订单中心和营销以及用户中心时序性耦合。具体来说，订单服务在创建订单的时候，需要同步调用营销中心的服务来计算优惠券，而计算优惠券的过程中，又需要营销中心同步调用用户中心，来获取用户的登记信息，来完成优惠金额的计算。从端到端业务场景的角度，订单中心，营销中心和用户中心都必须在线，并且可访问，下单才能顺利完成。因此在上边的场景中，我们说订单中心，营销中心和会员中心之间时序性耦合。 其实这种场景不需要关联的。

部署依赖: 这个比较简单，两个模块在一个项目下，A模块经常性变化，而B模块几乎不变化，但却因为A而经常走部署流程。

业务领域依赖： 这是非常复杂的依赖，对于这个依赖，艾瑞克伊凡提出了领域驱动设计的方法论。建立领域的通用语言，减少各角色对象之间的信息失真。

4. 业界常用的架构模式

软件行业无论是涉及到架构还是模式，总是有”选择困难症“，因为可供选择的方案总是很多。不过对于代码组织结构来说，业界主流的主要有：

• 1）Layered架构。mvc，四层架构等。
• 2）端口和适配器架构。六边形架构、洋葱架构等等。
• 3）CQRS架构。读写模式分离。主要是让下游业务只与R型业务流程进行关联，让一个变化只锚定一个地方。

请关注公众号“前沿科技bot“查看更多内容。