程序员进阶之路-架构的哲学

一、架构的尽头是哲学

工作时间久了以后，发现对框架(Spring)的了解还停留在一个基本会使用的阶段，对它的一些设计演进并没有一个全面的认识，在笔者经历过的团队中其实还存在一大部分程序员对分层的思想还是不甚了解，更别谈对项目的架构设计分层设计理念了，其实一个架构师尤其是一个有理想有追求的架构师一定是追求其框架设计演进过程和思想，然后转变成自己的设计和架构功底，这才是我们真正能够借鉴内化的。所以说，学会项目的架构分层是一个区别一个程序员是否合格的分水岭，更是一个架构师必须要掌握的基本功。

那么，肯定有一些刚入门的程序员会说，项目中为什么要分层呢？分层有什么好处呢？那笔者明确告诉你，分层有很多的好处，也有一些坏处，计算机的世界没有绝对的正确与错误，对于架构来说这一点尤为重要。一个架构师，重要的责任是做出优秀且正确的方案。一个优秀的架构师，是懂得取舍的，所有的架构方案不是最优的，但是一定是在特殊的阶段对投入和收益做出的折衷最正确选择。架构如此，人生亦如此，20多岁的女孩风华正茂，20多岁的男孩穷困潦倒，但是不能放弃对梦想的追求，重要的是一定要遵循客观规律基础之上，尽自己最大的努力。最后你会发现，无论你多么成功，我们的人生何尝不是在取舍中渡过呢！所以说架构的尽头是哲学！

二、架构分层的好处

那咱们首先看一下项目分层的好处：

• 系统解耦：我们的系统刚开始发展或者创建的时候，或许分层带来的好处没有那么明显，明显感觉增加了很多工作量。当系统越大，团队越多，需求变化越快时，越需要保证程序之间的依赖关系越少。而分层/面向接口编程，会使我们在应对变化时越容易，在越往后的业务地带过程中你会发现越来越得心应手，这就是系统解耦带来的非常棒的一点体验。
• 简化开发：当我们的系统越来越复杂，承接的功能越来越多的时候，有一些时刻我们或许想不明白从用户操作一直到数据落盘整个过程的交互情况时，我们应该换种方式思考。想想各层应该提供哪些支持，通过对各层分工的明确定义，复杂问题就变成了如何将各层功能组合起来的“积木搭建”。当笔者目前负责的中台项目开发需要对接不同的业务渠道的时候，这个好处点非常明显，其实分层说简单就简单，是一个项目的分层。当把这种思想放在系统服务封层的涉及理念是一样，比如目前的订单交易中台不仅仅对接电商业务，还对接门店业务，还对接不同地区的零售业务，等等，所以说，触类旁通就是说的这个道理。
• 易于维护：老多程序员在学习之初的时候很不了解，为什么所有的实现尤其是层之间对接的时候一定要设计成面向接口的，为什么我们这里体现了面向接口编程的优势。这里可以和大家说，分层之间的面向接口设计，我们正是为了后期的项目维护迭代工作，比如我们抽象出数据访问层后，只需要保证对外提供的接口不变，底层数据库使用Oracle还是MySql，上层结构是感知不到的。笔者曾经负责的一个电商项目，由于底层依赖的MQ没有采用这种面向接口的方式，随着公司基础架构的组件不断变迁，都需要我们做一些迭代升级，想一想全是痛苦啊。
• 功能复用：相信有一些工作年限比较长的程序员来说，尤其是有一些复杂项目业务开发经验的程序员来说，我们开发一些组件或者领域功能之后，发现好多的地方依赖这些功能，如果你更好的通过分层，明确定义各层职责，再也不会出现系统中多个地方查询同一个数据库表的代码。因为查询某个数据库表的工作只会由一个数据访问层类来统一提供，那么你后面的工作是不是越来越顺手啊，更多的时间可以做一些自己喜欢的事情。
• 易于配合：如果开发团队很多，项目中没有职责明确的分层，那么团队多人配合一定是一场灾难，项目也难以保障高质量交付，所以说通过分层和接口定义各团队只需要遵循接口标准/开发规范，就可以并行开发。

三、架构分层的缺点

到这，老多程序员说，你说的很有道理啊，觉得都是优点啊，哪有缺点？笔者在上面已经说过了，在计算机的世界里，引入一个新方案必然带来一个新问题，就像咱们初中物理学习的能量守恒定律那样，那笔者就系说一下引入分层带来的缺点：

• 如果想要分层设计的好，那么必须业务理解和团队沟通设计这一块投入比较大的精力，再也不是上来就干代码，而是所有的事情提前做好规划。
• 每一层做设计的时候，往往为了考虑兼容扩展后面的需求，如果生搬硬套会为了一些永远用不到的功能做一些设计，浪费了时间和精力。

那么，读者肯定会看出来。缺点绝对是大大少于优点的，所以说这个方案可行，那么咱们就需要分层，那么分层有哪几种呢？一般主要有2种分层架构思想，MVC分层设计和DDD领域建模分层设计。当然我也会介绍其他分层架构，但是没有MVC和DDD那么常用，我会一笔带过。MVC一般是3层，DDD一般是大四层设计，咱们不着急，一点点来，先说MVC的分层设计。

四、MVC架构分层

大家最熟悉的一定是MVC三层分层设计，因为目前绝大部门项目都是采用这种分层设计的，如果我们尝试把编程的复杂架构缩小到最容易理解的程度，那么MVC编程开发其实只做3件事：“定义属性、创建方法、调用展示”。但因为同类所需的内容较多，如一系列的属性，一堆的方法实现，一组的接口封装，那么就需要合理的把这些内容分配到不同的层次中去实现，因此有了分层架构的设计。

MVC架构模型适合提供HTTP服务的工程架构，适合简单的小场景开发使用。特点；轻便、简单、学习成本低。MVC 是一种非常常见且常用的分层架构，主要包括；M - mode 对象层，封装到 domain 里。V - view 展示层，但因为目前都是前后端分离的项目，几乎不会在后端项目里写 JSP 文件了。C - Controller 控制层，对外提供接口实现类。DAO 算是单独拿出来用户处理数据库操作的层。

（一）、MVC常见架构分层

MVC分层架构设计是将应用程序分为三个核心层次，即模型层、视图层和控制器层。这三个层次各自负责不同的功能，相互独立又相互联系。

模型层负责处理业务逻辑和数据持久化，视图层负责页面的布局和交互操作，控制器层负责业务逻辑和数据处理。这种分层架构设计可以实现代码的模块化、可维护性和可扩展性，提高开发效率和代码质量。

1.模型层的设计思路和实现方式

模型层是MVC分层架构设计中的核心层次之一，它负责处理业务逻辑和数据持久化。在模型层的设计中，我们需要关注以下几个方面：

• 数据库设计：根据业务需求，设计合理的数据库表结构，并实现数据访问层的接口。
• 业务逻辑实现：根据业务需求，实现相应的业务逻辑，包括数据验证、数据处理等。
• 数据持久化：通过ORM框架、DAO模式等方式，实现数据的持久化存储和访问。

2.视图层的设计思路和实现方式

视图层是MVC分层架构设计中的另一个核心层次，它负责页面的布局和交互操作。在视图层的设计中，我们需要关注以下几个方面：

• 页面布局：根据用户需求，设计合理的页面布局，包括页面结构、CSS样式等。
• 交互操作：根据用户需求，实现页面的交互操作，包括表单提交、页面跳转等。
• 数据展示：将模型层的数据以视图的形式展示给用户，并实现数据的动态更新。

3.控制器层的设计思路和实现方式

控制器层是MVC分层架构设计中的最后一个层次，它负责业务逻辑和数据处理。在控制器层的设计中，我们需要关注以下几个方面：

• 业务逻辑处理：根据用户请求和业务规则，处理相应的业务逻辑。
• 数据处理：根据业务需求，对数据进行处理、转换和验证。
• 请求响应：将处理后的数据返回给视图层，并更新用户界面。

（二）、MVC常见架构调用流程

• http请求，请求对象参数
• 进入contollr，http接口
• 进入service层，（枚举对象、实体对象、功能方法）
• 进入dao层（数据库交互、库表对象、数据库方法）
• 返回dao层数据
• 返回service层数据
• 返回contorller层数据

（三）、阿里巴巴架构分层规范

其实MVC是一种框架模式，而非设计模式，GOF把MVC看做是3中设计模式：《观察者模式》、《策略模式》，《组合模式》三者的合体。其核心是《观察者模式》。

笔者曾经见过很多种MVC的封层设计，总体来说大部分的设计都有一些问题，笔者结合多年的架构经验和设计经验，总结出来一套比较完整的设计方案，后来笔者在《阿里巴巴Java开发手册中》看到对分层的建议，有异曲同工之妙。

1.架构分层设计

• 开放接口层：可直接封装Service方法暴露成RPC接口；通过Web封装成http接口；进行网关安全控制/流量控制等。
• 终端显示层：各个端的模版渲染并执行显示的层。当前主要是velocity渲染，JS渲染，JSP渲染，移动端展示等。
• Web层：主要是对访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理等。
• Service层：相对集体的业务逻辑服务层。
• Manager层：通用业务处理层，它有如下特征：

对第三方平台封装的层，预处理返回结果及转化异常信息。

对Service层通用能力的下沉，如缓存方案/中间件通用处理。

与DAO层交互，对多个DAO的组合复用。

• DAO层：数据访问层，与底层MySQL、Oracle、HBase等进行数据交互。
• 外部接口或第三方平台：包括其他部门RPC开放接口，基础平台，其他公司的HTTP接口。

2.架构分层模型转换

以上的层级只是在原来三层架构的基础上进行了细分，而这些细分的层级仅仅是为了满足业务的需要。千万不要为了分层而分层。过多的层会增加系统的复杂度和开发难度。

那么分层有了，我们会引出另外一个问题，层和层之间的分层领域模型都有哪些呢，怎么做转换呢？

我们还是来看看《阿里开发手册》提供的分层领域模型规约参考：

• DO(Data Object)：此对象与数据库表结构一一对应，通过DAO层想上传输数据源对象。
• DTO(Data Transfer Object)：数据传输对象，Service或Manager向外传输的对象。
• BO(Business Object)：业务对象，由Service层输出的封装业务逻辑的对象。
• AO(Application Object)：应用对象，在Web层与Service层之间抽象的复用对象模型，极为贴近展示层，复用度不高。
• VO(View Object)：显示层对象，通常是Web向模版渲染引擎层传输的对象。
• Query：数据查询对象，各层接收上层的查询请求。注意超过2个参数的查询封装，禁止使用Map类来传输。

在给出的参考中并没有对模型对象进行非常明确的划分，特别是对BO、AO、DTO的界限不是非常明确。这也是因为系统处理的业务不同、复杂度不同导致的。所以在设计系统分层和建模的时候，需要综合考虑实际应用场景。

可能有些小伙伴会觉得麻烦，为什么要弄出这么多O？转来转去的多累！笔者举一个例子，拿笔者负责的订单商城个人订单列表举例子，相信大家对该业务都不陌生，比如，笔者个人中心总共有6个订单，每个订单会显示商品名称、商品价格、商品数量、商品图片等信息。

对于显示层来说，这些信息相对于分层的设计理念，是可以封装成一个VO对象的，因为咱们得购物车页面只显示这些信息，为了更好更方便的显示这些信息，我们可以将所有的属性都设计成字符串类型。

public class OrderVO {
  Long orderId;// 该订单的编号
  String orderTime;// 下订单的时间
  String orderStatus;// 订单状态
  String goodsNum;// 商品数量
  String goodsImage;// 商品图片
  String totalMoney;// 总金额
  String userName;// 用户姓名
  List<ItemsVO> orderItems; // 订单商品明细集合
}

那么对于MVC来讲，进一层的业务层怎么设计呢，这一层他关心的逻辑是什么？肯定的是跟咱们刚才设计的VO关注点肯定是不一样，他更加多住的是内部的业务逻辑关系，和页面显示是没有关系，大家这一点一定要好好理解哈。

public class OrderDTO {
  Long orderId;// 该订单的编号
  Integer orderTime;// 下订单的时间
  EnumOrderStatus orderStatus;// 订单状态
  Integer goodsNum;// 商品数量
  String goodsImage;// 商品图片
  BigDecimal totalMoney;// 总金额
  UserDTO userInfo;//用户信息
  List<ItemsDTO> orderItems;// 订单商品明细集合
}

可以看到，下单日期使用的Integer类型，金额使用BigDecimal，订单状态使用枚举值表示，用户名称变成了用户信息对象，明细集合中的商品也变成了DTO类型的对象。

在业务逻辑层面，更多的是关注由多种信息组合而成的关系。因为它在系统中起到信息传递的作用，所以它携带的信息也是最多的。

好，那我们再来看看数据持久层。

上面也提到了，数据持久层与数据库是一一对应的关系，而上一层的订单信息其实可以拆解为多个持久层对象，其中包含：订单持久层对象(OrderDO),商铺持久层对象(ShopDO)，用户持久层对象(UserDO)还有一堆的商品持久层对象(ProductDO)。

所以分层/拆分的本质还是简化我们思考问题的方式，各层只关注自己感兴趣的内容。

可这样的拆分确实增加了许多工作量，不同模型之间转来转去的确实头疼。

当然，Java丰富的生态给我们提供了很多转换的工具，在这里笔者就不一一细说了，大家感兴趣可以学习一下。

（四）、你用 MVC 写代码，遇到过最大的问题是什么？

简单、容易、好理解，是 MVC 架构的特点，但也正因为简单的分层逻辑，在适配较复杂的场景并且需要长周期的维护时，代码的迭代成本就会越来越高。

1.代码角度

• 瘦实体模型：只起到数据类的作用，业务逻辑散落到 service，可维护性越来越差。
• 面向数据库表编程，而非模型编程。
• 实体类之间的关系是复杂的网状结构，成为大泥球，牵一发而动全身，导致不敢轻易改代码。
• service 类承接的所有的业务逻辑，越来越臃肿，很容易出现几千行的 service 类。
• 对外接口直接暴露实体模型，导致不必要开放内部逻辑对外暴露，就算有 DTO 类一般也是实体类的直接 copy。
• 外部依赖层直接从 service 层调用，字段转换、异常处理大量充斥在 service 方法中。

2.项目管理角度

• 交付效率：越来越低。
• 稳定性差：不好测试，代码改动的影响范围不好预估。
• 理解成本高：新成员介入成本高，长期会导致模块只有一个人最熟悉，离职成本很大。

五、DDD架构分层

从最早接触 DDD 架构，到后来用 DDD 架构不断的承接项目开发，一次次在项目开发中的经验积累。对 DDD 有了不少的理解。DDD 是一种思想，落地的形态和结构会有不同的方式，甚至在编码上也会有风格的差异。但终期目标就一个：“提供代码的可维护性，降低迭代开发成本”。也是康威定律所述：”任何组织在设计一套系统时，所交付的设计方案在结构上都与该组织的沟通结构保持一致。“

但 DDD 与 MVC 相比的概率较多，贸然用理论驱动代码开发，会让整个工程变得非常混乱，甚至可能虽然是用的 DDD 但最后写出来了一片四不像的 MVC 代码。

如果你接触过较大型且已经长期维护项目的 MVC 架构，你就会发现这里的 DAO、PO、VO 对象，在 Service 层相互调用。那么长期开发后，就导致了各个 PO 里的属性字段数量都被撑的特别大。这样的开发方式，将”状态”、“行为“分离到不同的对象中，代码的意图渐渐模糊，膨胀、臃肿和不稳定的架构，让迭代成本增加。

而 DDD 架构首先以解决此类问题为主，将各个属于自己领域范围内的行为和逻辑封装到自己的领域包下处理。这也是 DDD 架构设计的精髓之一。它希望在分治层面合理切割问题空间为更小规模的若干子问题，而问题越小就容易被理解和处理，做到高内聚低耦合。这也是康威定律所提到的，解决复杂场景的设计主要分为：分治、抽象和知识。

（一）、DDD的专业名词

DDD的包含其中的一些基本概念，在此处大家先有个印象，先介绍几个主要的概念，后面会有专门的章节去介绍这些专业术语。

• 统一语言
• 限界上下文
• 领域、子域、支撑域
• 聚合、实体、值对象
• 分层：用户接口层、应用层、领域层、基础层

（二）、DDD的架构分层

└── src
    ├── Core
    │   └── Domain
    │       └── Entities
    │       └── ValueObjects
    │       └── Aggregates
    │       └── DomainEvents
    │       └── Repositories
    │       └── Services
    ├── Application
    │   └── Services
    │   └── DTOs
    └── Infrastructure
        └── Persistence
            └── EntityConfigs
            └── Migrations
            └── Seeders
        └── Repositories
        └── Factories

• 接口定义 - api：因为微服务中引用的 RPC 需要对外提供接口的描述信息，也就是调用方在使用的时候，需要引入 Jar 包，让调用方好能依赖接口的定义做代理。
• 应用封装 - app：这是应用启动和配置的一层，如一些 aop 切面或者 config 配置，以及打包镜像都是在这一层处理。你可以把它理解为专门为了启动服务而存在的。
• 领域封装 - domain：领域模型服务，是一个非常重要的模块。无论怎么做DDD的分层架构，domain 都是肯定存在的。在一层中会有一个个细分的领域服务，在每个服务包中会有【模型、仓库、服务】这样3部分。
• 仓储服务 - infrastructure：基础层依赖于 domain 领域层，因为在 domain 层定义了仓储接口需要在基础层实现。这是依赖倒置的一种设计方式。
• 领域封装 - event：触发器层，一般也被叫做 adapter 适配器层。用于提供接口实现、消息接收、任务执行等。所以对于这样的操作，小傅哥把它叫做触发器层。
• 类型定义 - types：通用类型定义层，在我们的系统开发中，会有很多类型的定义，包括；基本的 Response、Constants 和枚举。它会被其他的层进行引用使用。
• 领域编排【可选】 - case：领域编排层，一般对于较大且复杂的的项目，为了更好的防腐和提供通用的服务，一般会添加 case/application 层，用于对 domain 领域的逻辑进行封装组合处理。

（三）、DDD的优点

DDD（Domain-Driven Design，领域驱动设计）是一种软件开发方法论，旨在帮助开发者创建清晰和一致的领域模型。它提供了一种设计软件的方法，旨在解决复杂性问题，提高系统的可维护性和可理解性。

• 业务模型驱动：DDD鼓励从业务领域专家的视角来设计模型，确保软件模型反映了实际的业务逻辑和规则。
• 技术独立：DDD通过限界上下文（Bounded Context）将模型与实现细节隔离开，使得模型可以不受数据库实现方式的影响。
• 可扩展性：DDD通过分层架构（如Onion Architecture），可以轻松地重构代码以提高模块化和可扩展性。
• 适应性：DDD可以帮助组织应对快速变化的业务需求，因为它提供了一个框架，使得业务领域的知识可以轻松地融入到软件开发过程中。
• 适应复杂性：DDD提供了一种处理复杂问题的方式，它鼓励分解问题，并在适当的地方应用模式和实践。
• 教育性：DDD为开发者提供了一个框架，使得他们可以更好地理解他们正在开发的系统。

（四）、DDD的问题

• 一段业务逻辑代码，到底应该放到应用层还是领域层？
• 领域服务当成原来的 MVC 中的 service 层，随着业务不断发展，类也在不断膨胀，好像还是老样子。
• 聚合包含多个实体类，这个接口用不到这么多实体，为了性能还是直接写个 SQL 返回必要的操作吧，不过这样貌似又回到了 MVC 模式。
• 既然实体类可以包含业务逻辑、领域服务也可以放业务逻辑，那到底放哪里？
• 资料上说领域层不能有外部依赖，要做到 100% 单测覆盖，可是我的领域服务中需要用到外部接口、中央缓存等等，那这不就有了外部依赖了吗？

六、其他分层架构思想

（一）两层架构

1.出现时间：1960+，从个人电脑兴起时。

2.定义：一个服务器、多客户端。

3.架构图：

4.分层简介：

• 客户端：用户操作界面、页面展示；
• 服务端：业务逻辑、数据访问逻辑、数据存储、获取（RDBMS、NoSQL、In-Memory、TimeSeries、Graph）；

5.适用场景：

• 通用桌面应用程序；
• 电子邮件、文件系统、银行业务等在线应用；
• 游戏；

（二）三层架构/多层架构

1.出现时间：1990+：

2.定义：

• 展现层：页面展示、用户操作界面；
• 应用层：业务逻辑、数据访问逻辑；
• 数据层：数据存储、获取（RDBMS、NoSQL、In-Memory、TimeSeries、Graph）

3.架构图

4.适用场景

• Web 应用

（三）. MVC架构

1.出现时间：1980+

2.定义：

• Model：模型代表一个存取数据的对象或 JAVA POJO；在数据变化时更新Controller控制器；
• View：视图代表模型包含的数据的可视化；
• Controller：控制器作用于模型和视图上；它控制数据流向模型对象，并在数据变化时更新视图；让视图与模型分离开；

3.架构图：

4.适用场景：

• 主流开发语言互联网网页应用；
• Java: J2EE, Java Swing，SpringMVC

C#: ASP.NET

Python: Django

JS:Angular.js

PHP: …

（四）CQRS命令查询分离架构

1.出现时间：1985+

2.定义：

(1).展现接口层

• 视图、输入接口。

(2).Cmd/Query处理总线

• 命令总线：处理事务型请求。
• 查询总线：处理非事务型/查询类请求。

(3).应用层

用例，业务场景。

完成事务型操作。

(4).领域层

• 领域服务、事件、实体值对象等。
• 核心的业务规则，原子的业务操作。

(5).持久层

• 数据库、文件系统。

3.架构图：

4.适用场景：

• 业务复杂类；
• 对读写要求高，并发应用；

（五）、六边形/端口-适配器架构

1. 出现时间：2005
2. 定义：

(1).业务领域层

领域模型包含了所有的应用逻辑与规则。

领域层中不会直接引用技术实现，例如 HTTP 上下文或数据库调用，这样就能够确保在技术方面的改动不会影响到领域层面。

(2).端口层

负责接收与用例相关的所有请求，这些请求负责在领域层中协调工作；

端口层在端口内部作为领域层的边界，在端口外部则扮演了外部实体的角色；

(3).适配器层

这一层的技术实现负责以某种格式接收输入、及产生输出；

在适配器层不存在领域逻辑，它的唯一职责就是在外部世界与领域层之间进行技术性的转换；

两种类型的适配器：

• 入口/北向适配器
• 出口/南向适配器

3.架构图

4.适用场景：

• 提供多类型接口服务；
• 与多种设备、三方服务交互的应用；

（六）、洋葱架构

1. 出现时间：2008
2. 定义：

(1).业务实体（Entities）

• 业务实体（Entities）没有依赖；
• 组成了面向业务的领域模型，包括业务规则；

(2). 用例（Use Case）

一个用例规则有多个不同的业务规则组成；依赖业务实体；

(3). 接口适配器层

包含了网关（Gateways）、控制器（Controllers）与展示器（Presenters），它们皆属于适配器（Adapter），用于打通应用业务逻辑与外层的框架和驱动器，实现逻辑的适配以访问外部资源；

(4). web接口、资源层

包括页面、接口；

三方接口、数据库等；

3.架构设计图

4.适用场景：

• 复杂业务
• 接口服务；
• 多种设备、三方服务交互的应用；

六、本节总结

一个项目的架构一定是不断演进优化出来的，而不是在设计之初就一步到位的。这样作为一个架构师，才能够感受到业务需求对于项目多样性和复杂性的深刻理解，这样成长出来的架构师才是优秀的，这样的做出来的项目才有感情。就像我们的人生，没有人一开始就成熟，而是在不断地经历和学习中不断成长的，就像我们成长路上会经历很多的故事。

或许街头的红灯，见过最多的匆忙。或许医院的走廊，见过最多的悲伤。或许酒店的床，听过最多的谎话。或许佛前的香，听过最多的欲望。或许城市的霓虹，见过最多的迷茫。或许路边摊的酒杯，听过最多的梦想。或许伪装的坚强，最怕突然的关心。或许听歌的人，最怕唱的是自己。或许凌晨的耳朵，最怕家中的电话。或许清晨的眼睛，最怕见不到梦中的她。或许结痂的伤口，最怕再一次结痂。或许放下的记忆，最怕再一次放下。

我想，这就是被大家称作为成长的故事吧！人生如此，架构亦如此！欢迎大家和我一块走进DDD的世界，取其精华，去其糟粕！让DDD为我们的复杂业务项目插上梦想的翅膀！