This is the way：到底是谁的视角？

***本文源自一篇读者来信，是关于业务架构实施的问题，而且问题很有共性，所以我征得了读者的同意，保留原文并将我的答复以红字写在方括号中进行分享，以方便大家结合问题和问题的语境来阅读。有些圆括号中没有涂红的是读者来信内容，别读混了***

7、编排的视角是业务架构视角还是应用架构视角？

业务构件是业务架构范畴的概念，而应用构件是应用架构下的概念，业务构件指导应用构件的设计。那么在服务编排的时候，究竟是选择业务构件来编排还是选择应用构件来编排，说白了就是到底是站在业务还是技术的角度来进行编排？

如果是选择业务构件来编排，假如一个业务构件对应多个应用构件的话，编排操作人员如何知道其后对应了多个应用构件？站在业务人员的角度是否会存在遗漏编排的情况？

如果是选择应用构件来编排，假如一个业务构件对应多个应用构件的话，是否就需要技术人员参与编排？那么是否业务人员就不需要了？

【答：编排本身是应用视角，但是就设计源头来讲，应用构件之间的组合其实应该来自业务构件之间的组合需要。服务编排时选择的是应用构件，业务构件是向业务人员透出的，这里你可以想象产品模型的概念，产品模型是给业务架构组的产品建模人员用的，但实际上，经过适当培训是可以推给业务部门的产品管理人员用的，他们在产品研发平台上看到的产品组件、产品条件就是业务视角的业务构件和业务参数，在产品研发平台上配置完成后，推送给技术时，就是一个产品组件对应的服务的编排和参数设置需求，到了技术侧看到的就是应用构件或者说服务的编排。这里你想象Bizworks，它现在能做的就是把服务治理直接暴露出来在Bizworks上直接进行可视化编排，如果不需要改代码，那可以通过内置脚手架自动生成Jar包。在Bizworks的基础上增加应用模型和业务模型的关联，或者在产品研发平台上增加业务模型对应用模型的关联，其达到的效果都是我前边介绍的效果，对于大部分不用改代码的产品更新就可以这样实现。至于视角其实是站在了业务和技术拉通的视角上进行编排，如果没有拉通，就跟各做各的差不多了，那样的服务未必能满足下一次组合的要求。如果一个业务构件对多个应用构件，业务构件没变则意味着应用构件没变，如果业务构件有变化，则双方都可以很快清楚是对着哪些构件在谈问题，这一点与上边一样，关键是不要只想着这就是万能的复用，它既是复用的模式，但同时也是需求沟通和定位工具，可以快速锁定需求范围。至于遗漏的问题，从业务完整度的角度来看，一般不会遗漏编排，因为产品模型是可以基于模板进行复制设计，通过已有的产品模板改出新产品，这一点对于构件模型也一样，往往可能被遗漏的会是需求。无论业务和技术之间谁是一对多，其实我都建议构件的打磨由双方共同进行，而打磨成熟的构件的使用，应该是业务侧向技术侧推，而不是站在技术人员的视角上，其实，从深度融合的角度来讲，双方都需要对方的视角】

8、编排的维度是否应该统一？

目前我们线上产品分为客户线上申请阶段（信息录入、人脸识别、风控判断）和人工线下审核阶段，和线上申请阶段不同，线下核实是按照岗位职责来走的，比如客户经理提交到支行行长，但做的事情主要是客户经理是维护信息，支行行长是仅仅审核信息但不能输入，如客户经理需要做：电话核实、维护影像、维护风险信号，但支行行长需要做：审核电话核实结果、审核影像、审核风险信号，假如将线上和线下做的任务全部以业务构件的形式来提供，那么当进行编排的时候，有两种方式：

（1）第一种编排方式：信息录入->人脸识别->风控判断->电话核实->维护影像->维护风险信号->审核电话核实结果->审核影像->审核风险信号，也就是线上按照功能，线下按照岗位职责来编排；

（2）第二种编排方式：信息录入->人脸识别->风控判断->电话核实/查看电话核实结果->维护/查看影像->维护/查看风险信号，也就是不管线上线下都按照功能来编排，但是就要求一部分业务构件需要在里面区分岗位职责以实现输入还是只读属性；

以上两种方式哪一种好一些？

【答：就我个人看是第二种会好些，首先，服务数量少了，这样的划分如果在类似地方都相同处理，服务可能少很多；其次，核实和审核原本也是一对儿，可能只改了数据状态，追加了操作人的关联关系，二者变化关系一般也会在一起；最后，取消某一项时，拿掉一个服务即可，组合也不容易遗漏】