随着微盟大客化战略的推进，微盟服务的商户业务场景越来越复杂，在用户端，商户会有一个店铺使用多个小程序，且每个小程序的业务功能不一样的诉求。为了支持此类场景，我们提出了“端应用”的概念，端应用能够对产品功能（产品）进行打包，通过在店铺下创建多个端应用，每个端应用分别打包不同产品并绑定指定小程序，实现多小程序及不同小程序间的业务功能差异化。商户希望不同业务可以用不同的小程序承载，因为这些业务之间边界相对比较分明，同时也希望能给用户传达更明确的使用场景，提升使用体验。另外还有一些业务场景，商户想要创建多个小程序，每个小程序的功能一样，使用不同小程序用于多个渠道的推广引流。在微盟 WOS 中，我们将业务功能的最小单元定义为了“产品”，比如商城、CRM、导购等，通过对不同产品的组合、打包可以构建出满足不同行业场景的“解决方案”。我们发现，商户在上述第一个场景中对小程序提供功能的划分维度与 WOS 对产品的划分维度是基本一致的，比如商城业务小程序对应商城产品、会员业务小程序对应 CRM 产品等，所以是不是可以类比解决方案打包的概念，对小程序提供的用户端功能也以产品的维度进行打包？答案是可以。对于打包的这个“包”，我们称之为“端应用”。再进一步，端应用间可以打包不同产品，那就也可以打包相同的产品，自然的就解决了上述第二个场景的诉求。核心概念
端应用是商户C端拥有的产品功能的组合。端应用 ID 的字段名叫 CID 。默认端应用，每一个 BosID 包含唯一一个默认端应用，在监听到 BosID 第一次购买产品生成实例的消息时生成。默认端应用包含 BosID 下所有在用状态的产品实例。自定义端应用，商户创建的自定义打包产品实例的端应用。产品实例与端应用的关系
1、 端应用打包的时候，需要明确定义包含了哪些产品实例。渠道与端应用的关系
1、 一个端应用可以包含多个渠道，例如微信小程序，公众号、H5、抖音小程序、支付宝小程序等。同个端应用内的不同渠道，端应用 ID 相同。2、 同个端应用中，需要做到用户打通；同商户下的多个端应用，用户是否打通应该可选。上下游与端应用的关系
1、端应用监听产品履约发出的购买产品和退订产品的消息，来创建和初始化默认端应用，增加和剔除端应用中被退订的产品实例。3、端应用管理在端应用发生变更时，发出端应用变更事件，通知下游业务。(1) 端应用中维护非退订状态的产品实例，如果一个产品实例被退订，那这个产品实例将从端应用中剔除。(2) 默认端应用关注这个店铺下全部的产品实例状态。(3) 自定义端应用关注用户自行关联的产品实例状态。端应用的使用与渠道授权场景密切相关，为了保证商户的使用体验，端应用的管理功能融入到了渠道授权场景中，将渠道授权、端应用创建、端应用绑定串联为了一个整体流程。以小程序授权场景为例，其产品主流程如下：微盟值客推是一个基于微盟 WOS 的 D2C 电商营销解决方案，该解决方案通过丰富的营销方式使用多个小程序在不同渠道进行用户触达，解决电商行业自然流量少、成交效果差、复购转化难等问题。在该解决方案中，通过创建多个端应用并打包值客推解决方案的相关产品，每个端应用绑定一个微信小程序，实现了同一店铺下多微信小程序的场景。产品与组织节点之间是有开通关系的，端应用打包了产品，理论上在端应用中是可以访问所有产品所开通的组织节点的。所以，再进一步推演，组织节点与端应用的关系除了这层默认关系外，也是可以进行管理的，即端应用中可使用的组织节点可以通过配置进一步约束。端应用的远期规划重点在于组织节点与端应用关系的管理能力，基本思路如下所述。端应用与组织节点之间是关联关系，一个端应用可以分配给多个组织节点使用。1、 BosID 拥有多个端应用，一个端应用唯一归属于一个 BosID。即 BosID 与端应用是1：n的关系2、 端应用可以分配给多个 vid 使用，一个 vid 上可以有多个端应用。即 vid 和端应用是 n:m 的关系3、 vid 基于开通的产品实例，天然与产品实例相关的端应用产生了关联，端应用的分配需要基于这种关联。如下图所示：● 红色线的关系表示 vid 能不能使用某个端应用● vid 和产品实例没有关系的情况下，就不可能分配相关的端应用● 绿色线的关系表示让不让 vid 使用某个端应用在微盟 WOS 体系内，端应用基于产品体系、组织架构体系等 WOS 底层能力实现了良好的灵活性和扩展性。端应用能力有效地支持了值客推解决方案的上线，基于公司业务的发展，端应用的远期方案也将逐步落地，与下游业务方协作满足商户的业务诉求。用数据讲故事——可视化在数据产品界面中的妙用
微盟移动端组件库 Titian Mobile 对外开源
微盟WOS商业操作系统孵化新业务实战案例