-
基本结构 = 入口 + 内核 + 依赖 内核 = 简单逻辑 + 复杂流程 简单逻辑 = 业务脚本 + 能力执行 复杂流程 = 流程编排 + 节点衔接 + 能力（任务）执行 -
演化 = 主题讨论 + 组件选取（市场组件优先）
▐ 入口
VSEF 观点：入口要清晰明确
就像 “要理清乱了的线团，就要找到线头一样”，将入口放在一个完整的目录，或者模块中的好处是：可以快速地功能总览，了解“提供哪些服务”、“接收那些消息”、“实现哪些任务”。
这里的目录类型有：
服务 service : 对外提供的 rpc 服务， 如HSF。这个一般会搭配一个服务 client 可调用者使用。
消息 message：可以再区分 metaq 和 notify 目录。
调度 scheduler：一些调度任务。
业务入口
▐ 内核
内核结构
-
流程 l3.process：进行业务活动编排，理解整个请求要完成什么事情。 -
活动 l4.activity：提供每个执行步骤的能力，代表了事情的关键节点。 -
能力（任务） l5.ability：节点执行时要做的一些具体任务，期望包装为能力，具备一定的复用性。
简单流程，主要是只读服务，如查询数据等，可以直接进入服务脚本 service。简单服务直接使用 l5能力（任务）。当逻辑逐渐复杂的时候，可以重构为复杂流程。
VSEF 观点：完成任务需要使用的资源都是依赖，依赖皆服务。服务都通过 l5能力 进行使用。
l5 能力在进行具体操作的时候，需要从数据、扩展、外调、中间件等渠道获取需要加工的数据，形成自己的理解。这个过程中，依赖的东西被称为“依赖”，通过“服务”的方式进行集成。
▐ 依赖
可以放进依赖的类型：
存储实现 repository : 数据库的读写操作。
中间件使用 middleware：包括缓存（tair）、发送消息（metaq、notify）、配置（diamond、switch）等。
网关实现 gateway：外部系统的调用，比如订单服务、退款服务等。
扩展实现 extension：业务差异性设计的扩展能力，需要业务提供扩展插件，或者平台代写。
VSEF 观点：基础设施是否易变，可自行判断，稳定时可以直接依赖。
这里值得讨论的是：如果基于六边形架构，这些基础设施被视为具体实现，应该通过抽象接口，依赖倒置的策略，实现解耦。但是实际在大家的系统中，可以判断其易变性，如果长期保持稳定的话，可以减少依赖抽象这一层，直接依赖基础设施，减少抽象成本，在思考层面做到 less is more。
VSEF 的目录只是一个初始化、相对简单的系统结构。如果随着业务的发展，各个组成部分会逐渐臃肿，系统风格可能也会变化。所以需要引入一些主题的讨论，结合业务情况进行一些设计，并选取相关组件，进行集成，形成有具体组织特征的、新特性的应用结构。
VSEF 观点：演化后的系统结构，结合了功能特性，才是各个组织的合适的系统结构。
注重平台服务的：关注平台逻辑和扩展机制。
注重组件表达的：与用户有交互，需要关注组件化协议。
注重领域协作的：需要关注协调者的模型和设计、应用内的领域划分逻辑。
注重数据服务的：关注数据能力性能、功能范围、数据模型映射。
VSEF 主题
▐ 组件协议
如果系统是平台型的，并且带界面表达，那么需要解决的就是各个端、各个页面、各个业务不一样的扩展能力。在内部模型和视图模型之间增加一层ViewModel, 然后基于这个进行各种转换，是不错的思路，比较典型的组件有：奥创、Astore等。
这里细化开来，关于 ViewModel 能够有多定制，有2个不同的走向：
转换主要在组件框架中：在核心逻辑之外，进行各种框架植入，如奥创、Astore, 在数据出口侧进行转换，转换的手段一般是基于规则表达式，利用相关反射能力进行数据组装。
转换主要在业务扩展中：不想在组件框架中承载过多代码，想和业务普通扩展逻辑走的近一些，在系统执行过程中的扩展逻辑中，植入视图的扩展，可以较好匹配前台组件。
奥创&DinamicX 方案运行原理
▐ 活动编排
流程编排是对一个业务操作执行过程进行进一步的划分，常见的编排组件有：Tbbpm、SmartEngine 等。但在实际开发过程中，常常会有这样的疑惑：为什么是这几个节点？为什么是这样的顺序？
为什么是这些节点？
-
是不是调用了一个服务？那么准备服务参数，调用，返回结果判断可以包装为一个节点。 -
是不是都在操作一个对象？那么这些操作可以归类为：初始化，修改，转换等内聚的方法。 -
是不是一些通用的处理？比如安全校验、日志监控、数据统计等。 -
是不是存在业务扩展性？可以单独独立出来，作为抽象方法，或者使用组合，提供相关接口定义。
-
为什么是这样的顺序
-
上下文数据依赖 -
本身地位：需要对最终结果进行收口，需要最后执行。 -
系统框架要求必须进行初始化先执行 -
其它等等
-
每个顶点出现且只出现一次 -
若存在一条从顶点 A 到顶点 B 的路径，那么在序列中顶点 A 出现在顶点 B 的前面
排序的背后是依赖
▐ 设计模式
-
模版方法 ：模版方法是说对一个执行过程进行抽象分解，通过骨架和扩展方法完成一个标准的主体逻辑和扩展。平台和扩展能力的设计，做类比是比较合适的。基础的模版就是整个流程的编排和对应的节点，可扩展的地方就是各种业务定制区域。这样形成了平台和业务较好的融合。 -
策略模式 ：策略是说完成一个事情有不同的算法，可以进行相关切换。在逆向退款中，需要支持不同的退款链路，有些需要是担保交易，有些是保证金链路，有些是微信支付，有些是退卡、退资产。为了支持多种出账策略，采用了策略模式，可以通过扩展点定制各种资金策略。 -
责任链模式 ：责任链是说将请求让队列内的处理器一个个执行，直到找到愿意执行的。扩展中，在执行回收结果的时候，会遍历实现的插件，并结合回收规则，进行及时的熔断。 -
观察者模式 ：观察者模式是说我们通过注册、回掉这样的协作设计，完成变化通知的协作机制。系统间基于消息的观察模式还是很多的。通过消息的异步通知方式，既可以较好地进行解耦，也可以在失败时利用消息的重投机制，增加成功的概率。 -
中介者模式 ：当多个类之间要协调的时候，往往引入中介者进行协调，减少大家的知识成本。系统中的流程执行过程中，会有一个大的上下文，这个上下文会协调各个领域的数据。
▐ 元数据
认知复杂性：度量理解软件所需要的努力，即捕获程序的逻辑流，并度量逻辑流的各种特性。
▐ 复用独立
单刃为刀，双刃为剑。们在用这个双刃剑的时，当一面对着敌人，另一面一定会对着自己，这时如果将剑刃对着敌人砍去的时候，敌人用兵器一挡，剑就会反弹回来，对自己就会有一定的危险。
代码复用是一把双刃剑。复用意味着代码的影响面会增加，虽然提高了开发效率，但是一但进行改动，影响范围变大的副作用也很明显：要求你得足够了解影响的范围，进一步增加了认知的复杂性。在影响较大的情况下，不合理的复用会产生很多令人崩溃的补丁逻辑。
有时，为了业务独立快速迭代，会独立逻辑，因为我们预判一直演化下去最终可能会产生两份完全不同的代码。
有时，虽然业务逻辑看上去不太一样，但是我们会收口到一起，尽量复用一份逻辑，因为我们预判发展下去会产生更多的复用逻辑。
到底是分还是合？哪些要复用？哪些要独立发展？显然与我们的预判息息相关。总的来说，离“业务”越近的地方，应该越尽可能独立，离“平台”越近的地方，应该近可能复用，代码是否稳定是重要的判断因素。
▐ 领域划分
在VSEF里面，淡化了领域的概念，因为认为领域都在网关服务里面，而系统本身的领域，则分散在能力里面，对外整体作为一个领域。
-
思想一：看核心管理数据载体。 我们可以认为一个域实际上是一个或多个实体对象的信息集合，并对所管理的实体对象的生命周期进行管理。 -
思想二：确定核心白名单，其它可扩展。 既然无法维护一个涵盖整个企业的统一模型，那就不要再受到这种思路的限制。通过预先决定什么应该统一，并实际认识到什么不能统一，我们就能够创建一个清晰的、共同的视图，然后需要用一种方式来标记出不同模型之间的边界和关系。
此外，我们常常会发现划分调整的背后事务：
调整的内容：其实是匹配生产关系。
调整的原则：追求职责的内聚，精细化分工。
不断调整的原因：业务在发展，内聚的标准需也要与时俱进。
从关联的角度看，往往我们看组织架构，就能看到领域的边界，核心原因还是组织架构也是要适应生产关系，follow更优解的结构，是相辅相成的，也就能互相窥探。
▐ 逻辑模型
在数据库操作的时候，在数据服务的路口，选择逻辑模型是天然的一个选择。比如属性，在逻辑模型中可能是一个map，在DO中是一个String，如果使用DO流转，就会非常不方便。
这里还可以探讨的是，逻辑模型应该如何抽象？要不要聚合多个表。最容易理解、维护以及发展的情况，当然是领域模型与数据模型能够形成1：1的维护关系。但是由于底层数据很难变动，而理解和业务发展是与时俱进的，当我们持续设计的时候，逻辑模型势必会不太一样。常见的一些场景有：
一个逻辑模型维护一个表：这个是比较简单的场景，一个逻辑模型直接负责一个表，比较干净易理解。
多个逻辑模型共享一个表：这个是因为表中记录的数据比较多，但是实际上有不同的领域数据存的冗余储，比如交易订单上的营销优惠信息、资金信息、物流信息等。
一个逻辑模型维护多个表：当我们对原始的领域重新划分，又不能重新建立表结构的时候，对于较大的一些域，往往数据来自多个表，这时候就会遇到这样的情况，一个领域模型要从多个数据库表里面聚合数据。
聚合逻辑模型的复杂情况：这个在DDD里面主要是聚合根这样聚合了多个实体的情况。举个例子来说，资金单有支付单、垂直表、还有多个支付单，这样的聚合关系就更加复杂了。
▐ 模型策略
-
共享内核 shared kernel ：通常是共享核心领域或者是一组通用子领域。 -
客户/供应商关系 customer/supplier ：上下游关系。不同客户需要协商来平衡，上游团队需要有自动测试套件。 -
跟随者模式 conformist ：单方面跟随模式。上游的设计质量较好，容易兼容，可以采用严格遵循上游团队的模型。 -
防腐层 anticorruption layer ：防腐层、隔离层，使用 facade 等模式，减少其它系统变动对本系统的影响。 -
各行其道 separate way ：声明一个与其它上下文毫无关联的限界上下文，使开发人员能够在这个小范围内找到简单、专用的解决方案。
▐ 扩展机制
如果只是基于模式扩展，可能采用一些局部的策略模式就可以了。但是如果期望服务多个业务，且期望隔离业务定制，那么就需要提供一些插件包，隔离权责出来。
每个层次都可以设计自己的扩展机制
无论是扩展框架TMF的迭代，还是后面星环体系的提出，一个重要的目的是为了解决“业务和平台的隔离”，这也是开闭原则的重要体现。核心逻辑应该由比较熟悉的平台人员进行控制，应该尽量通用，较少修改；扩展逻辑应该由业务开发人员理解，应该尽量灵活，便于调整。
往系统内部看，其实还有很多域能力的扩展，比如：支付的时候可以走直连支付宝，也可以经过支付系统链接到微信等非支付宝渠道。这样的扩展，也是开闭原则的体现，只是离核心流程更近，影响面更大。
往扩展外部看，即使是业务APP包、产品包等插件内部，还是可能会服务多个行业、多个场景，可能有很多的再次路由与扩展。比如：淘系要服务很多行业，服饰、家电等，不同业务定制也不太一样，往往会用一些策略、责任链的扩展模式。
组件选取
不同业务组织，在进行相关主题的讨论与思考后，会定制一套适合自己的发展结构。后面在快速启动的时候，期望有一些复用的组件。这部分组件，分为外部市场的组件，和自己建立的组件。
组件分为市场已有的组件，还有自己期望自建的组件，这里VSEF框架中会提供一些概念组件。
▐ 市场组件
市场组件应该被优先选择，因为那个是服务更多场景的，有更强的包容性。当然，如果系统比较小除外。如果定位比较大，那么还是建议及早引入，随着流量的增加，理解也不断增加，越到后面，越能巧妙应用。
交易系统中使用的一些组件举例如下：
协议化组件：Ultronage、Astore
流程编排组件：Tbbpm、SmartEngine
扩展组件：Lattice、TMF
配置化组件：Newton
▐ VSEF组件
-
元数据组件 ：Metadata ， 期望能够生成知识索引数据。 -
日志组件 ：CommonLog，期望能够统一格式，方便统一监控、清理。 -
预热组件 ：Preheat，期望能够抽象接口预热方式，便于预热操作。 -
适配器组件 ：Adapter，一些市场组件的抽象包装，快速集成。 -
扩展组件 ：Extension，简单扩展组件，解决系统扩展性问题，且不那么得重。
VSEF组件的一些案例
本文介绍了一些简洁架构VSEF的一些框架结构理解，并且抛出了一些演化的主题，这些主题的不同思考会让系统发展成不同的风格，实际也是应用定位的必然结果。最后介绍了一些组件的部分，这个部分应该是水到渠成的结果，而不应该是事先预设的标准。
本文分享自微信公众号 - 大淘宝技术（AlibabaMTT）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。