系统架构：系统分层和数据分层

引言

大家也许都听过这样一句话“软件=数据结构+算法”，这句话也许不容易理解，转化为更易理解的方式，也许可这么说：一个软件系统包括系统的业务逻辑以及业务逻辑相关的数据或数据流，打个比喻的话，业务逻辑就如同动物的骨骼，而数据则是动物身上的肌肉；而在传统意义上，我们所说的软件的分层化、组件化，更多描述的是软件业务逻辑，数据被我们人为的忽略了，其实数据也是存在分层的，今天笔者就为大家深入的阐述一下数据的分层化，首先笔者带领大家了解数据的分层化概念，然后说明数据的模型概念，最后我们落脚到C++内核的跨平台APP分层约束和数据约束。

分层化

如前所述，系统的分层包括业务逻辑分层和数据分层，此章节我们主要系统的阐述软件分层模式，当然在阐述数据的分层化之前，首先还是先温习业务处理的分层化描述，接着业务分层我们继续阐述数据的分层；

业务分层

本文介绍阿里编码规范中的分层约束，如图一所示：

图一  逻辑分层图

• 开放接口层：
  1. 开放接口层可以直接依赖Service层也可依赖WEB层；
  2. 依赖Service层，可将 Service 封装成 RPC 对外暴露；
  3. 依赖WEB层，可以将业务封装成 HTTP对外暴露。
• 终端显示层：
  1. 负责各个端的模板渲染并执行显示；
  2. 当前主要是 velocity 渲染，JS 渲染，JSP 渲染，移动端展示等；
• Web层：
  1. 对访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理等；
• Service层：
  1. 主要负责具体的业务逻辑服务实现；
• Manager通用业务处理层，主要职责包括：
  1. 对第三方平台封装：对Service层通用基础组件的封装，如缓存、中间件通用处理；
  2. 与DAO层交互，对多个DAO的组合复用
• DAO 层：
  1. 数据访问层，与 MySQL、Oracle、Redis等进行数据交互。

数据分层

将数据模型添加到业务分层，即可得到数据的分层约束，如图二所示，

图二  数据分层图

其中：VO(Value Object)表示前端展示的值对象，DTO(Data Transfer Object) 表示数据传输对象；DAO(Data access object) 数据访问对象；BO(Business Object) 业务对象；PO(Persistant Object) 持久对象；DO（ Data Object）：数据对象，正常情况下与PO等价。

数据模型

前一章节主要介绍了数据的分层，本章主要介绍数据分层中涉及的数据模型对象以及彼此的差异。

模型介绍

VO(Value Object)

VO（Value Object）：前端界面展示，Value Object值对象，View Object表现层对象，主要对应界面展示的数据对象，用于展示层，它的作用是把某个指定页面（或组件）的所有数据封装起来。对应WEB页面/SWING界面，VO对应整个界面的值，Android 代表Activity或view的数据元素。

PO(Persistant Object) 持久对象

持久化对象，它跟持久层（通常是关系型数据库）的数据结构形成一一对应的映射关系，如果持久层是关系型数据库，那么数据表中的每个字段（或若干个）就对应PO的一个（或若干个）属性。

DO(Data Object) 数据对象

在绝大多数情况下，DO和PO是一一对应的，没有任何差异，仅仅在某些场景中存在差异，在章节[3.2.1]会详细产生两种的差异。

DTO（ Data Transfer Object） 数据传输对象

泛指用于展示层与服务层之间的数据传输的对象，还有一种情况就是在需要跨进程或远程传输（RESTful请求）时的传输对象，它不应该包含业务逻辑。

BO（Business Object） 业务对象

BO（ Business Object）业务对象，主要用于service层或service之间数据封装。业务对象 （Business Object，BO）主要作用是把业务逻辑封装为一个对象。这个对象可以包括一个或多个其它的对象。通常一个 BO 包含多个 PO，通常需要将 BO 转化成 PO，才能进行数据的持久化，反之，从 DB 中得到的 PO，需要转化成 BO 才能在业务层使用。BO 建议只包含业务方法。

模型对比

不论VO、DTO、BO、DO 还是PO,有一点是可以肯定的：那就是他们都是数据，都是不同层次和场景中对特定数据的封装，不包含任何业务流程和操作。但因为使用层次和场景不同所以彼此有存在显著的差异，下面我们就从不同的角度给出彼此的差异对比

PO与DO

在大部分时间内，PO和DO是一样的，PO一般与数据库密切关联，对应关系型数据库，PO的每个属性对应数据库表的一个字段，DO侧重于内存驻留，而不侧重数据库的持久化层。举个例子：设计一个商品折扣策略，在折扣策略实现过程中会涉及到相关数据DO存储，但是在数据库中就不会有一个PO与之对应。

BO和DO

BO面向业务层的对象，主要完成对业务的封装，BO对象可以包括一个或多个其它的对象。举一个求职简历的例子，每份简历都包括教育经历、项目经历等，我们可以让教育经历和项目经历分别对应一个 PO，这样在我们建立对应求职简历的 BO 对象处理简历的时候，让每个 BO 都包含这些 PO 即可。

DAO和DO

DAO（Data Access Object）数据访问对象，它是一个面向对象的数据库接口，负责持久层的操作，为业务层提供接口，主要用来封装对数据库的访问，常见操作无外乎 CURD。我们也可以认为一个 DAO 对应一个 PO的对象，它位于业务逻辑与数据库资源中间，可以结合 PO 对数据库进行相关的操作。

C++内核跨平台APP分层约束

C++具有较好的跨平台特性，因此基于C++内核进行跨平台APP开发也是不错的选择。下图三是笔者正在开发的一个跨平台APP的架构。

​​图三  APP系统架构图

从系统架构图，我们可以看出，本APP的UI层和系统抽象层都采用系统原生语言开发，而系统的核心业务却是采用C++开发，然后通过胶水代码实现与原生语言的转换。因为存在语言隔离，因此对本APP来说业务分层和数据分层是至关重要的，否则UI层将很难获取到C++核心业务层中的数据和业务实现，核心业务层将无法与系统抽象层进行数据和业务交互。

业务约束

从整个系统架构出发，我们C++跨平台APP架构需要满足下述业务约束：

• 把UX页面交互相关的抽象到UI层；
• 把平台无关的核心业务抽象到C++业务核心层；
• 平台相关的业务抽象到UI层，因此在业务约束中，业务的层次划分还有公共业务流的抽象是至关重要的，它决定了APP开发成败与否；
• 而系统抽象层负责实现系统抽象，实现应包括：线程，网络，文件操作等，而不应该包含任何业务，否则会导致系统抽象层因业务变更而不停的变化。

数据约束

数据约束同业务约束同样重要，我们C++跨平台APP架构需要满足下述数据约束：

• 公共业务流必须带有数据，业务流操作和运作的产出就是不同层次的数据，我们在设计中需考虑到数据在不同层次的展现形式和格式，这里所述的不同层次的数据展现形式就是前文中所述的DO,VO,DTO,BO等；
• 而且还可能存在组件间的数据隔离约束，以图三架构为例，可能会存在Message Service专属的数据描述，它对于Video Service不可见，同样对于UI层Video相关的业务也是不可见的；
• 如果数据分层和约束不清晰，就会导致在App开发过程中抽象接口不停的变更，增加软件开发和测试的成本。