当一个应用系统上部署多个“业务模块”的时候，我们期望有一个统一的结构模版，这个结构模版是“业务架构”和“技术架构”的一个重要衔接，本文就是对这个结构模版的一些探索。
原型
▐ 结构设计
先回顾一下《简洁应用框架VSEF的架构》中提到的总体结构。
VSEF 总体结构
▐ 结构样例
模块：
- 客户端：vsef-archetypes-client
- 业务逻辑：vsef-archetypes-application
vsef-archetypes-application 目录结构：
原型目录结构截图如下： 
原型目录结构截图
▐ 执行模版
业务流程 l3.process 处理背后，可以考虑一些共性的东西，作为模版，减少重复工作，常见的一些点有：
- 异常如何处理
- 是否有幂等需要
- 是否需要并发加锁
- 是否需要提供组件协议
- 是否有数据库和消息操作
- .......
在原型示例处理流程中，继承了处理模版。
示例处理流程继承处理模版
这个模版里面植入了“幂等校验与处理”的抽象。
处理模版中抽象了“幂等校验与处理”逻辑
【延伸扩展】下面是V2交易框架中的一个比较复杂的处理模版，可以作为抽象的大图参考。
▐ 模型抽象
除了处理过程的抽象，我们有时也会都处理的上下文进行抽象，可以节省各个流程的转换过程。
因为我们处理模版中，没有非常复杂的具体逻辑包装，同时为了不对使用者提供太多约束，所以模型只是简单的输入 Request、输出 Result 抽象。
原型中处理模版对模型的抽象
但是，随着业务活动的增多，是可以进一步细化，但这也意味着通用性会降低，这不应该属于通用框架的部分，会属于具体落地的效能讨论主题，这里就不展开了。
【延伸扩展】下面会展示一下V2里面的最终模型模型逻辑，可以做为后续设计的一个参考。
案例
▐ 价保 priceinsurance
- 场景介绍
主要功能：基于下单的订单信息，重新请求营销等系统，计算当前价格和价差，进行赔付。
V2 价保业务活动分析
- 原型结构
原型选取4个入口案例：申请价保服务、提交价保服务、申请并提交服务、异步check消息处理。
主要的结构如下图所示：
价保原型功能结构大图
- 关注点
业务活动组合
价保中有个场景是“申请并提交价保服务”，这个服务需要结合“渲染价保服务”、“申请价保服务”。这里的处理策略可能有这样几种：
- Process独立：新写一个“申请并提交价保处理流程”，独立编排。
- Process聚合：写一个“申请并提交价保服务”，调用“渲染价保服务”、“申请价保服务” 的 l3.process 服务。
- API 聚合：写一个“申请并提交价保服务”，调用“渲染价保服务”、“申请价保服务” 的API实现。
价保中采用的是API聚合，因为除了核心逻辑，比如错误码的转换、限流等，都会包含在API里面，所以为了尽可能得保持逻辑一致，还是在当做黑盒处理比较好，聚合服务不要去理解原子服务背后的具体细节。
抽象模型
价保的模版中，模型的抽象保留了“减少约束”的思想，直接用抽象类型，且无继承约束。
价保的处理模版模型抽象约束为无
这样做有个非常舒服的案例是“异步check”消息的处理，可以直接使用消息处理的上下文，作为Request和Result，减少了转换陈本。当然，这会造成很难复用活动节点，这里采用服务脚本直连能力的方法是比较好的。但是在模型抽象层面的思考还是有意义的。
使用消息输入输出作为处理流程的上下文
业务身份能力
价保有个业务身份能力，需要计算业务身份实例，用于后面的扩展寻找插件。这里业务身份的策略是：follow下单时的业务身份。
价保业务身份计算能力
扩展服务机制
扩展作为一种服务，其扩展机制是可以自定义的。
在价保原型中，会议一些校验、价差计算、渲染的业务扩展，为了支持这些扩展，扩展区域主要设计了几个模块：
- ext - 扩展服务模块 ：扩展服务的实现，负责寻找插件，回收结果。
- plugins - 插件模块：实现业务扩展的插件，可以托管在应用代码库内，也可以通过二方包方式集成进来。
- sdk - 扩展SDK模块：模型和方法定义，作为衔接 ext 扩展服务 和 plugins 插件实现的桥梁。
价保扩展服务设计
▐ 拼团 groupon
- 场景介绍
主要功能：招商侧可提报优惠、团信息；下单时，基于设置信息进行hold订单，当支付订单数达到成团人数，则拼团成功，创建物流单；否则，拼团超时失败，快速退款，关闭订单。
拼团业务活动分析
- 原型结构
原型选取2个入口案例：订单支付消息、拼团查询服务。
主要的结构如下图所示：
拼团原型功能结构大图
- 关注点
业务脚本
拼团原型中，有一个查询的case。这个case中，直接使用了业务脚本服务，在业务脚本中调用了 l5.ability 中的数据能力获取了数据，并进行了简单转换。
拼团查询服务直接使用 l5.ability
子流程串联
拼团的时候，接到付款消息，需要区分开团订单还是参团订单，走不同的处理流程。在“参团or开团流程”中展示了如何串联2个业务脚本。
"参团or开团流程" 串联了2个子业务流程
数据操作
拼团和价保都是一样的，操作数据的时候，通过定义依赖接口进行解耦，同时模型会使用业务能力中的“领域模型”，不会直接依赖DO。数据服务，负责理解领域依赖接口，实现数据转换。
拼团数据服务不直接依赖DO
总结
由于follow原型结构，价保、拼团的项目结构是一样的。如果对这个类似的“应用架构”进行边界定义，当一个应用上部署多个“子业务应用”的时候，可以类比 docker 的思想的，做较多的统一服务（更多的可以是理解层面），也便于新业务模块的快速初始化。与 docker 的差异是，这种抽象程度进一步走进了具体的业务单元。
业务应用架构 - 业务逻辑层的“集装箱”
团队介绍
我们是交易平台-平台产品服务团队。团队主要从事交易链路交付工作，在交付工作中，抽象和建设横向产品能力（如：预售、电子凭证等），团队关注业务架构、DDD等理论与实践，致力于高效、稳定地实现业务接入，并抽象赋能。
