产品核心特征
产品核心特征总结为5点：低门槛、一站式、泛业务、高定制、高集成。
- 低门槛
- 一站式
由于是应用开发的平台，目前开发平台最直接的方式就是写代码。但是我们需要意识到，由代码构建的系统就是对客观运行的业务系统规律的一种描述方式，这种方式并不是唯一的，只不过目前受制于生产力或者说技术工具亦或是技术手段，才导致目前编码几乎是唯一的开发平台的有效方式，也就是形成这样的链路：业务需求 --> 开发编码 --> 应用系统。如果我们可以把中间的开发编码环节替换掉，变成更容易使用的门槛更低的方式，即：业务需求 --> 开发平台 --> 应用系统，门槛的降低将支撑起更多的用户，此外操作的简化将带来效率的提升与错误率的降低。因此，宜搭平台自创建开始，就是定位给无编码基础的用户，希望可以附能于非开发岗位的业务同学，帮助他们去实现自己的业务系统。这里的用户特制使用宜搭平台进行开发的用户，而宜搭平台开发的系统面对的用户是不会变的，就是业务同学。 - 一站式
承接用户定位，要求平台必须提供一站式的能力，包括研发流程支撑、开发环境支撑、运行环境支撑、监控运维支撑等等。研发流程支撑，传统的为：提交需求—>确定产品方案—>评审—>开发—>测试—>验收—>上线，横跨多人甚至多个团队部门，往往还需要立项来管理，研发上也需要考虑设计、安全、适配性等等问题，使用宜搭平台之后，这些工作均可以交给一个人来完成，效率大大提高。开发环境支撑，传统的JAVA WEB项目，需要自己使用框架编写代码，并申请数据库、应用服务器、缓存、消息队列、文件存储等等来进行支撑，成本较高，并且使用这种方式编写的代码无法跨系统复用。运行环境支撑，传统的需要运行在自己的服务器上，而使用宜搭平台之后，由平台提供，背后对用户完全不可知，并且后续也提供了丰富的升级可能。监控运维支撑，传统的方式，业务数据需要自己埋点监控，而由宜搭平台提供之后，全部交由平台管理，在平台统一查看。 - 泛业务
由于不指定支撑的业务领域，因此要求平台的模型更加的抽象。抽象始于“特殊”归于“一般”，要求宜搭去收集大量的场景，提炼出背后的一般规律，精炼出模型和逻辑。宜搭在初始阶段，调研了行政、财务、法务、IT、资产等等业务，决定使用页面、逻辑、数据这三块作为底层的核心模型。经过2000多个应用的实践打磨，基本证明了这条路的可行性。 - 高定制
由于需要支撑各个领域的业务，并且即使是相同领域的相同业务场景，其需求受到时间地点人员等等制约，也可能是不一样的。如何设计一个高定制的研发平台，其实就是在可变性和封装之间获取一个平衡，封装程度越高，用户使用成本越低，但是其响应变化的能力越差，以国外产品infor为例，其将沉淀了数十年的业务领域封装为领域模型，开放出来的仅仅是预先设置好的数据属性字段配置以及业务逻辑扩展点，假设这个业务领域发生了变革，那么影响是致命的。而如果放弃了领域模型的封装，那么可变性必然会提高，但是用户的使用成本将大大上升，并且无法实现业务模型的复用。为了响应用户更灵活的需求，宜搭在设计上选择了后者，并且已经想到了针对这个问题的解决方案，就是分层，下文会展开描述。 - 高集成
企业软件架构设计阶段里面，有一个重要的考虑环节就是架构迁移规划。假设宜搭平台已经足够成熟，成为了企业应用搭建中台之后，老的系统迁移到新的系统架构也是需要时间的，如何一步一步安全平滑稳定的迁移，中间的过渡方案是什么，都是需要考虑的问题，更何况宜搭平台还处在产品的创新摸索阶段。在DT时代，要求我们在数据和应用层面打通，提供一体化的体验，实现各个系统间的连接，因此就需要强大的开放和集成能力。开放指的是平台提供标准，供其他系统调用，而集成指的是平台调用其他各个系统，这里面就需要用到依赖倒置的思想，将需要集成的其他系统的服务规范起来。
产品架构
针对上述对产品的思考，宜搭的产品架构设计如下：
- 应用使用者
宜搭提供了对内和对外两个版本，内部版包括了正式、外包和生态化公司员工，外部版包括了钉钉和第三方企业用户。再细分一下，宜搭平台的用户被划分为两类：应用管理员和应用访问者。应用管理员即是搭建应用的用户，而应用访问者指的是搭建完成的应用的最终使用者。 - 输出端
目前宜搭未提供自己的APP端，使用阿里内外以及钉钉来承载，此外也有自己的H5页面。 - 宜搭平台
分为两态，即管理态和运行态。管理态仅支持PC访问，提供给应用管理员来创建编辑发布应用；运行态支持PC以及移动端访问，提供给应用访问者即真正的业务用户。 - 基础依赖
宜搭平台提供一站式的解决方案，集成了框架、中间件、等诸多基础服务。
针对5个产品核心特征，在产品设计和技术设计上，宜搭也有自己的思考和打法。
1 . 低门槛
1.1. 认知模式
目前我们去构建一个软件系统，领域建模方法推荐的方式就是使用一致的语言去描述一个一致的模型，让产品、开发和测试都可以达成共识。而后根据这个一致的模型即领域模型，去实施开发方案。随着阿里巴巴中台化战略在集团内推广以及在国内的影响力，领域建模的重要性也得到了越来越多的共识。但是对于不具备编码基础的业务人员，他们并不具备领域建模的能力。因此，在项目初始阶段我们进行了评估，宜搭平台决定先采用表单驱动的方式来进行业务建模，这个方式更加符合我们应用管理员用户的认知。随着平台的发展，宜搭平台承担的业务也越来越复杂，而不少业务人员自身，已经具备了建模甚至是编码的能力，因此宜搭平台考虑下一步，新增领域视图建模范式，作为目前表单建模范式的升级。这个也启发我们，随着业务人员自身的更迭升级，当编程能力已经成为类似英语的基础技能的时候，我们的产品形态会变成什么样子呢？
1.2. 可视化
作为最直观最高效的表达方式，可视化已经成为了产品的标配。目前宜搭实现了页面绘制、流程编排、数据呈现上的可视化，管理员用户通过拖拽和选择等方式，就可以实现整个应用的搭建。但是如何把页面、逻辑和数据，完全可视化的展示在用户面前，仍然是一个十分困难的课题，尤其是逻辑这一层，以流程为例，一个人工节点就有10+以上的配置项，并且用户不可见的内置底层配置项还有不少，且可能不断地演化升级。因此如何让用户精确地将自身的操作本身和背后的运行逻辑建立完全1对1的映射关系，是需要解决的关键问题，也是宜搭下一步重要的努力方向，即新增业务领域层。
1.3. 简洁
在用户界面设计上，简洁是一个一直奉行的原则，让用户仅感知到最核心的内容，随后在一层一层引导用户来完成所有的操作。宜搭平台奉行的简洁原则，还有一层“精简”的含义，在第一个版本直接去掉了大量的已有功能，仅保证了一个最简系统的闭环。这样做大大降低用户门槛的同时，也加速了系统的上线，此外通过倾听用户的反馈，也可以辅助我们去评估需求的优先级，进而指导我们进行功能迭代。
1.4. 快捷操作
针对用户的常用且配置相对繁琐的操作，宜搭封装了快捷操作方式。除了快捷键的使用之外，在功能上宜搭也提供了关联表单组件功能来实现页面组件之间的联动，提供了关联表单数据和条件数据关联来满足不同数据源之间的关联需求等等。
2 . 一站式
2.1. 自动化
当用户定义完自身的页面逻辑以及数据后，自动帮用户完成整个运行环境的部署。页面使用统一标准的schema语言定义，前端页面选择react框架渲染，每一个最小业务单元封装为组件，在PC端使用H5页面渲染，在移动端结合app特性，调用对应的native api进行渲染适配，提升用户体验。中间的逻辑层，目前尚未隔离和独立部署，所有的业务逻辑全部运行在共同的服务器上，这块是可以结合集团基础设施等团队来共同协作的，以提供高可用的服务。最底层的数据层，目前也均是采用统一的存储引擎存储，不过这块宜搭使用了分层的数据架构，因此设计上预留了扩展的可能，可以进行改造，使数据层支持物理上的独立部署。
2.2. 多租户
目前宜搭使用的是逻辑上的标识，将应用服务和应用数据完全隔离开。就像上文自动化中提到的，后续宜搭会考虑支持物理上的隔离，做到应用独立部署和数据独立部署。由于使用了统一的平台框架来进行开发，方便用户开发的同时，也在无形之中添加了约束规则，因此降低了应用弹性扩容、服务治理、数据切换迁移的难度，为后续部署架构的升级提供了极大支持。
3 . 泛业务
不特指业务，因此目标可以支持所有的业务
3.1. 通用模型
表单、逻辑、数据为核心的模型，来源于对业务的理解和抽象，也比较符合大众直观的感觉。但是这个概念太大，在实施上，宜搭寻求了最小的业务闭环，表单模型包括了组件、布局样式、以及常用的事件和行为；逻辑模型一期仅支持了流程，后续才逐渐开放了公式、脚本、规则的能力；数据模型则直接读取表单模型的字段，自动优化字段类型和索引，而后基于此，提供了单数据集数据在线聚合分析和展示的能力，多数据及关联以及复杂的在线离线数据抽取转换清洗功能陆续上线中。
3.2. 分层思想
3.2.1. 领域模型层
上文提到，宜搭平台放弃了领域模型的封装，直接暴露更底层的能力，使用业务的灵活性换取了业务的复用性。宜搭马上会上线的应用模板市场，可以在一定程度上解决复用性的问题，提升搭建效率，但是这将导致领域模型被频繁的复制修改，好比一段代码被在系统中出现了很多处，并没有本质上解决问题。解决这个问题的思路方法就是增加领域模型层，同时宜搭平台的用户角色也将进行调整，用户角色在之前的应用管理员，应用访问者基础上，在增加领域模型管理员。领域模型管理员，使用现有的宜搭系统来搭建领域模型，而应用管理员则可以直接使用搭建好的领域模型进行业务开发，这个模型封装了绝大多数的业务规则，仅暴露了必要的配置能力。这种分层的方式，优雅的解决了业务灵活性与业务复用性的问题。
3.2.2. 数据层
宜搭数据层也使用了逻辑和物理存储分离的架构设计。分离出逻辑层是因为宜搭底层可能使用多套混合的存储模型，来支持泛业务的场景，逻辑层需要去路由判断目前请求命中的底层存储引擎是什么，进而去请求物理存储层。
3.3. 能力升级
这块提到的能力升级，指的是通用模型的能力升级。表单、逻辑、数据模型都考虑到了升级的可能。目前表单设计器渲染器宜搭集成的是乐高产品的引擎，数据模型这块集成的是AirBI的能力，但是集团内包括集团外部，相关的产品相当多，每个产品均有自己的优势和劣势。从通用泛业务开发平台来讲，兼容并包是指导思想，甚至可以一键升级到写代码的模式，才能最大程度保证所有需求的可落地性。所以，需要支持各项能力的升级。表单模型和数据模型在下文集成部分会描述，逻辑模型在下文高定制的时候会描述。
4 . 高定制
4.1. 逻辑编排
这个是业务的核心。宜搭第一个版本仅支持了两种主要的内置核心业务逻辑流，分别是单据和流程，以及评论等次要业务逻辑流。下图是一个简单的实例，竖着看每一条均代表了一种业务逻辑流，虚线框代表了生命周期。 每种业务逻辑流有各自的生命周期，生命周期的各个阶段将抛出事件，可作为扩展点，事件被接受后可以触发对应的执行插件进行业务逻辑的执行。因此宜搭逻辑编排核心就是事件驱动机制。只不过目前是内置的两种业务逻辑流。下一步宜搭平台计划引入更加灵活的逻辑编排方案，基于当前满足BPMN2.0规范的工作流引擎进行封装，实现业务编排。这里面异常处理和分布式事务是重点要考虑的两个问题，其中异常处理可以参照BPMN规范中的异常启动事件处理逻辑，但是分布式事务方面会遇到不少问题，考虑使用GTS来解决。
4.2. 扩展点
作为触发的入口，逻辑十分简单，只需要在对应的阶段抛出特定的事件即可。需要注意的是，尽可能全生命周期均支持扩展点，拆分的尽量精细。
4.3. 执行插件
目前宜搭集成了诸多插件服务，包括但不限于公式、钉钉邮件消息、打印、电子签章等等，目前平台架构在大多数扩展点上是支持插件动态注册和执行的。但是我们注意到，单纯由我们去集成贡献插件是效率低下，并且耗时耗力的事情，因此提出了构建插件市场的开放模式，平台角色再增加一个插件管理员，由他们来贡献插件。宜搭平台期望可以共建一个生态系统，激活更多的开发者加入宜搭的生态体系，形成规模效应。从商业化角度来讲，渠道商是最赚钱的，这将成为宜搭重要的一个商业模式。因为我们有阿里巴巴的品牌背书，所以我们更容易去号召市场，来实现宜搭生态体系的构建。插件用户可以在平台上注册插件，编写适配代码，提交审核发布，如下是简化的插件执行设计示例。 
5 . 高集成
5.1. 接口开放
这块主要指服务端接口，即控制逻辑和数据上面。目前宜搭提供了20个接口，分为流程实例、单据实例和任务中心三类，具体可参考文档：https://www.yuque.com/yida/help/ihxi9r
5.2. 接口集成
5.2.1. 执行插件层
插件可能来自各个系统，如果由宜搭平台去适配调用各个系统，对于整个系统的扩展性是非常不利的。在架构设计上，引入了防腐层，由平台提供通用的调用协议，并且提供适配器的注册通道，将平台和各个系统连接在一起，这就是依赖倒置思想的体现和实践。每个待接入的插件或者系统，按照平台规范在平台上来开发实现适配器，就可以保证新插件的接入，平台层和外部系统层均不用改动，也符合开闭原则。
5.2.2. 数据层
由于要支持泛业务，因此也需要强大的集成能力，比如针对在线的数据存储与访问，数据库这块基本上非关系型nosql，关系型olap、oltp都得支持。因此，宜搭制定了数据逻辑层的统一SPI数据接口规范，并抽象了宜搭的数据物理层，以在物理层上支持不同的业务使用不同的存储引擎。宜搭数据层的终局，将使用分层策略加上应用的数据架构的独立隔离部署，可以类比JVM的JIT或者mysql的索引选择策略，针对请求的接口和参数两个维度，去动态计算判断最合适的存储引擎，进而进行数据的保存，查询与处理。为了支持更好的性能，存储层还使用了缓存、水平分片、冷数据归档等等策略。
技术架构
上文描述了宜搭的核心设计与思考，宜搭目前的技术架构设计如下，宜搭架构后续有若干的升级点，上文也均针对目前的想法进行了分享，就不在下图体现出来了：
最后的话
后续，我们在逻辑层会增强，透出代码二开能力；整体应用会使用弹性化托管方案，进一步降低成本；应用和插件上，也将开放入驻能力，让更多的开发者参与进来，共建整个生态。
