简洁应用框架VSEF的架构

本文介绍了一些简洁架构VSEF的一些框架结构理解，并且抛出了一些演化的主题，这些主题的不同思考会让系统发展成不同的风格，实际也是应用定位的必然结果。

总体

VSEF 架构理念 = 基本结构 + 演化

基本结构 = 入口 + 内核 + 依赖
内核= 简单逻辑 + 复杂流程
简单逻辑 = 业务脚本 + 能力执行
复杂流程 = 流程编排 + 节点衔接 + 能力（任务）执行
演化 = 主题讨论 + 组件选取（市场组件优先）

VSEF 总体结构

核心架构

架构 = 组成要素 + 关系 + 设计/演化原则

▐ 入口

VSEF 观点：入口要清晰明确

就像 “要理清乱了的线团，就要找到线头一样”，将入口放在一个完整的目录，或者模块中的好处是：可以快速地功能总览，了解“提供哪些服务”、“接收那些消息”、“实现哪些任务”。

这里的目录类型有：

服务 service : 对外提供的 rpc 服务，如HSF。这个一般会搭配一个服务 client 可调用者使用。
消息 message：可以再区分 metaq 和 notify 目录。
调度 scheduler：一些调度任务。

业务入口

▐ 内核

业务逻辑进入之后，常见的结构是 Service + Component + Mapper。但随着操作链路的增多，会逐渐交织耦合，变得复杂。所以，需要一些设计，包括：纵向的分层、横向的目录划分、并定义复用的区域，缓解代码安放问题造成的复杂度。

VSEF 观点：内核 = 简单逻辑 + 复杂流程

内核结构

复杂流程，主要是写入服务，或者是带页面表达的详情服务，采用流程分类框架（Process Classification Framework，PCF）。进入到应用的时候，主要分为3层：

流程 l3.process：进行业务活动编排，理解整个请求要完成什么事情。
活动 l4.activity：提供每个执行步骤的能力，代表了事情的关键节点。
能力（任务） l5.ability：节点执行时要做的一些具体任务，期望包装为能力，具备一定的复用性。

流程分类框架 PCF 层次

简单流程，主要是只读服务，如查询数据等，可以直接进入服务脚本 service。简单服务直接使用 l5能力（任务）。当逻辑逐渐复杂的时候，可以重构为复杂流程。

VSEF 观点：完成任务需要使用的资源都是依赖，依赖皆服务。服务都通过 l5能力进行使用。

l5 能力在进行具体操作的时候，需要从数据、扩展、外调、中间件等渠道获取需要加工的数据，形成自己的理解。这个过程中，依赖的东西被称为“依赖”，通过“服务”的方式进行集成。

▐ 依赖

可以放进依赖的类型：

存储实现 repository : 数据库的读写操作。
中间件使用 middleware：包括缓存（tair）、发送消息（metaq、notify）、配置（diamond、switch）等。
网关实现 gateway：外部系统的调用，比如订单服务、退款服务等。
扩展实现 extension：业务差异性设计的扩展能力，需要业务提供扩展插件，或者平台代写。

依赖内容

VSEF 观点：基础设施是否易变，可自行判断，稳定时可以直接依赖。

这里值得讨论的是：如果基于六边形架构，这些基础设施被视为具体实现，应该通过抽象接口，依赖倒置的策略，实现解耦。但是实际在大家的系统中，可以判断其易变性，如果长期保持稳定的话，可以减少依赖抽象这一层，直接依赖基础设施，减少抽象成本，在思考层面做到 less is more。

主题演化

VSEF 的目录只是一个初始化、相对简单的系统结构。如果随着业务的发展，各个组成部分会逐渐臃肿，系统风格可能也会变化。所以需要引入一些主题的讨论，结合业务情况进行一些设计，并选取相关组件，进行集成，形成有具体组织特征的、新特性的应用结构。

VSEF 观点：演化后的系统结构，结合了功能特性，才是各个组织的合适的系统结构。

这样的系统结构可能会彼此差异很大，会成为不同的类型，就像七个葫芦娃一样，核心本领各不一样：

注重平台服务的：关注平台逻辑和扩展机制。
注重组件表达的：与用户有交互，需要关注组件化协议。
注重领域协作的：需要关注协调者的模型和设计、应用内的领域划分逻辑。
注重数据服务的：关注数据能力性能、功能范围、数据模型映射。

VSEF 主题

下面，会基于VSEF的主题，简单谈一下思考，有了这一部分，才会知道如何去选择组件，而不是“被组件的厚重所绑架”，避免为了用而用，实际并不合适。

▐ 组件协议

如果系统是平台型的，并且带界面表达，那么需要解决的就是各个端、各个页面、各个业务不一样的扩展能力。在内部模型和视图模型之间增加一层ViewModel, 然后基于这个进行各种转换，是不错的思路，比较典型的组件有：奥创、Astore等。

Model-View-ViewModel（MVVM）模式

这里细化开来，关于 ViewModel 能够有多定制，有2个不同的走向：

转换主要在组件框架中：在核心逻辑之外，进行各种框架植入，如奥创、Astore, 在数据出口侧进行转换，转换的手段一般是基于规则表达式，利用相关反射能力进行数据组装。
转换主要在业务扩展中：不想在组件框架中承载过多代码，想和业务普通扩展逻辑走的近一些，在系统执行过程中的扩展逻辑中，植入视图的扩展，可以较好匹配前台组件。

奥创&DinamicX 方案运行原理

▐ 活动编排

流程编排是对一个业务操作执行过程进行进一步的划分，常见的编排组件有：Tbbpm、SmartEngine 等。但在实际开发过程中，常常会有这样的疑惑：为什么是这几个节点？为什么是这样的顺序？

为什么是这些节点？

这和我们看到一段非常长的代码，把它切分成几个方法是类似的。关键是切分的依据是什么？常用的一些划分点有：

是不是调用了一个服务？那么准备服务参数，调用，返回结果判断可以包装为一个节点。
是不是都在操作一个对象？那么这些操作可以归类为：初始化，修改，转换等内聚的方法。
是不是一些通用的处理？比如安全校验、日志监控、数据统计等。
是不是存在业务扩展性？可以单独独立出来，作为抽象方法，或者使用组合，提供相关接口定义。

切分的背后是理解

为什么是这样的顺序

基于这些切分原则，可以对一个执行过程的核心要点进行切分，切分完后排序的依据是什么？为什么一定要是这样的顺序？这个问题本质是需要了解各个部分的依赖关系，这些依赖关系可能是：

上下文数据依赖
本身地位：需要对最终结果进行收口，需要最后执行。
系统框架要求必须进行初始化先执行
其它等等

那么我们可以去梳理这些依赖关系，形成一个有向无环图，最后变成寻找了拓扑排序这样的问题：

每个顶点出现且只出现一次
若存在一条从顶点 A 到顶点 B 的路径，那么在序列中顶点 A 出现在顶点 B 的前面

有时候，这个顺序是唯一的，但是大多数时候这个顺序是不唯一的，所以我们更应该去了解内部的依赖关系，而不是纠结于表面的顺序。

排序的背后是依赖

▐ 设计模式

在比较重的业务逻辑处理过程中，除了集成一些框架、目录与jar包层次的设计之外，比重最大的启示是普通 java 代码，而这些能够影响最大的是，是设计原则与设计模式。这些应该是不能忽略的点。

常见的场景举例有：

模版方法：模版方法是说对一个执行过程进行抽象分解，通过骨架和扩展方法完成一个标准的主体逻辑和扩展。平台和扩展能力的设计，做类比是比较合适的。基础的模版就是整个流程的编排和对应的节点，可扩展的地方就是各种业务定制区域。这样形成了平台和业务较好的融合。
策略模式：策略是说完成一个事情有不同的算法，可以进行相关切换。在逆向退款中，需要支持不同的退款链路，有些需要是担保交易，有些是保证金链路，有些是微信支付，有些是退卡、退资产。为了支持多种出账策略，采用了策略模式，可以通过扩展点定制各种资金策略。
责任链模式：责任链是说将请求让队列内的处理器一个个执行，直到找到愿意执行的。扩展中，在执行回收结果的时候，会遍历实现的插件，并结合回收规则，进行及时的熔断。
观察者模式：观察者模式是说我们通过注册、回掉这样的协作设计，完成变化通知的协作机制。系统间基于消息的观察模式还是很多的。通过消息的异步通知方式，既可以较好地进行解耦，也可以在失败时利用消息的重投机制，增加成功的概率。
中介者模式：当多个类之间要协调的时候，往往引入中介者进行协调，减少大家的知识成本。系统中的流程执行过程中，会有一个大的上下文，这个上下文会协调各个领域的数据。

......

常见的策略模式

▐ 元数据

当内部结构开始复杂的时候，就期望使用一些元数据。一方面，期望这个能够将理念传达给开发者，知道对应类的角色。另一方面，这部分的扫描，可以形成结构知识，并通过各种数据转存，在另外一个系统无关的页面进行展示，可以站在更高地抽象和中文描述层次，更好地方便大家理解。

认知复杂性：度量理解软件所需要的努力，即捕获程序的逻辑流，并度量逻辑流的各种特性。

简单元数据设计

▐ 复用独立

单刃为刀，双刃为剑。们在用这个双刃剑的时，当一面对着敌人，另一面一定会对着自己，这时如果将剑刃对着敌人砍去的时候，敌人用兵器一挡，剑就会反弹回来，对自己就会有一定的危险。

代码复用是一把双刃剑。复用意味着代码的影响面会增加，虽然提高了开发效率，但是一但进行改动，影响范围变大的副作用也很明显：要求你得足够了解影响的范围，进一步增加了认知的复杂性。在影响较大的情况下，不合理的复用会产生很多令人崩溃的补丁逻辑。

有时，为了业务独立快速迭代，会独立逻辑，因为我们预判一直演化下去最终可能会产生两份完全不同的代码。
有时，虽然业务逻辑看上去不太一样，但是我们会收口到一起，尽量复用一份逻辑，因为我们预判发展下去会产生更多的复用逻辑。

到底是分还是合？哪些要复用？哪些要独立发展？显然与我们的预判息息相关。总的来说，离“业务”越近的地方，应该越尽可能独立，离“平台”越近的地方，应该近可能复用，代码是否稳定是重要的判断因素。

订单管理系统中复用独立的不同场景

▐ 领域划分

在VSEF里面，淡化了领域的概念，因为认为领域都在网关服务里面，而系统本身的领域，则分散在能力里面，对外整体作为一个领域。

领域中，关于领域的划分是很非常挑战的，相关思考，在我们的能力划分，目录的设计等方面都可以借鉴：

思想一：看核心管理数据载体。
我们可以认为一个域实际上是一个或多个实体对象的信息集合，并对所管理的实体对象的生命周期进行管理。
思想二：确定核心白名单，其它可扩展。
既然无法维护一个涵盖整个企业的统一模型，那就不要再受到这种思路的限制。通过预先决定什么应该统一，并实际认识到什么不能统一，我们就能够创建一个清晰的、共同的视图，然后需要用一种方式来标记出不同模型之间的边界和关系。

此外，我们常常会发现划分调整的背后事务：

调整的内容：其实是匹配生产关系。
调整的原则：追求职责的内聚，精细化分工。
不断调整的原因：业务在发展，内聚的标准需也要与时俱进。

从关联的角度看，往往我们看组织架构，就能看到领域的边界，核心原因还是组织架构也是要适应生产关系，follow更优解的结构，是相辅相成的，也就能互相窥探。

领域的划分应该尽可能正交

▐ 逻辑模型

在数据库操作的时候，在数据服务的路口，选择逻辑模型是天然的一个选择。比如属性，在逻辑模型中可能是一个map，在DO中是一个String，如果使用DO流转，就会非常不方便。

这里还可以探讨的是，逻辑模型应该如何抽象？要不要聚合多个表。最容易理解、维护以及发展的情况，当然是领域模型与数据模型能够形成1：1的维护关系。但是由于底层数据很难变动，而理解和业务发展是与时俱进的，当我们持续设计的时候，逻辑模型势必会不太一样。常见的一些场景有：

一个逻辑模型维护一个表：这个是比较简单的场景，一个逻辑模型直接负责一个表，比较干净易理解。
多个逻辑模型共享一个表：这个是因为表中记录的数据比较多，但是实际上有不同的领域数据存的冗余储，比如交易订单上的营销优惠信息、资金信息、物流信息等。
一个逻辑模型维护多个表：当我们对原始的领域重新划分，又不能重新建立表结构的时候，对于较大的一些域，往往数据来自多个表，这时候就会遇到这样的情况，一个领域模型要从多个数据库表里面聚合数据。
聚合逻辑模型的复杂情况：这个在DDD里面主要是聚合根这样聚合了多个实体的情况。举个例子来说，资金单有支付单、垂直表、还有多个支付单，这样的聚合关系就更加复杂了。

逻辑模型与物理模型映射场景

▐ 模型策略

当我们获得外部对象的时候，选择follow，还是选择拷贝，还是选择抽象定义。这里有不同的策略：

共享内核 shared kernel ：通常是共享核心领域或者是一组通用子领域。
客户/供应商关系 customer/supplier：上下游关系。不同客户需要协商来平衡，上游团队需要有自动测试套件。
跟随者模式 conformist：单方面跟随模式。上游的设计质量较好，容易兼容，可以采用严格遵循上游团队的模型。
防腐层 anticorruption layer：防腐层、隔离层，使用 facade 等模式，减少其它系统变动对本系统的影响。
各行其道 separate way：声明一个与其它上下文毫无关联的限界上下文，使开发人员能够在这个小范围内找到简单、专用的解决方案。

战略设计策略

▐ 扩展机制

如果只是基于模式扩展，可能采用一些局部的策略模式就可以了。但是如果期望服务多个业务，且期望隔离业务定制，那么就需要提供一些插件包，隔离权责出来。

更为主要的是，不同的插件包，在运行态如何执行，如果有多个满足条件，该如何定义优先级。这里逃不掉的是一个插件身份的定义。这个定义可以有很多的玩法，不同的业务组织可能理解不一，这可能是扩展机制的核心难题。

每个层次都可以设计自己的扩展机制

无论是扩展框架TMF的迭代，还是后面星环体系的提出，一个重要的目的是为了解决“业务和平台的隔离”，这也是开闭原则的重要体现。核心逻辑应该由比较熟悉的平台人员进行控制，应该尽量通用，较少修改；扩展逻辑应该由业务开发人员理解，应该尽量灵活，便于调整。
往系统内部看，其实还有很多域能力的扩展，比如：支付的时候可以走直连支付宝，也可以经过支付系统链接到微信等非支付宝渠道。这样的扩展，也是开闭原则的体现，只是离核心流程更近，影响面更大。
往扩展外部看，即使是业务APP包、产品包等插件内部，还是可能会服务多个行业、多个场景，可能有很多的再次路由与扩展。比如：淘系要服务很多行业，服饰、家电等，不同业务定制也不太一样，往往会用一些策略、责任链的扩展模式。