This is the way：总会聊清楚的

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

9、我们目前正在设计中，但是我们想产品工厂将来是偏向应用视角的，而我们现在又有一个建模工具，就是维护产品四层结构，产品条件等信息的，更像是拿到需求之后的分析设计使用，和产品工厂还是有些区别。所以想看看，建模工具站在业务架构角度，产品工厂站在应用架构角度对应用进行编排，这样有没有问题。。。但这样的话就不知道是否有必要再维护业务构件和应用构建的关联关系

答：其实逻辑上是不应该分开的，因为业务构件和产品组件其实是一个含义。分开的思想其实就是最初我们做产品的思想，尤其是技术看这个问题的思想。我们当初把产品模型都做成了两个，一个叫设计态，业务用的，一个叫研发态，技术用的。

10、当时XX在做企业架构的时候，是全行所有条线都参与了改造么，我感觉对于零售信贷领域是比较合适的，因为各地分行特色产品实在太多了，而对于对公产品就比较稳定，还有支付领域也是，我理解不是所有业务领域都涉及到企业架构改造吧？

答：领域是都涉及到了，不过对公确实不容易做，产品化程度不一样。

11、我们的设想是零售领域经常变化，涉及到编排等功能，但公司产品比较稳定，可能只是涉及到一些逻辑功能的分支，也就是通过产品条件去选择，组件编排可能用不上，就是您说的产品化程度的差别？

答：对，产品化的核算，基于产品的管理，这个是很多领域都必须有的，至于编排只是产品化的一部分，根据设计需要来做。

12、付老师，关于编排的问题，我还是有点疑惑。编排的时候是不是编排个顺序即可，有没有必要去指定当前这个构件的输入输出和上下游构件的映射

答：如果从bizworks这个工具实践的视角看，是可以指定的

问：我明白您的意思了，我们的业务场景老说，大部分的业务场景是需要人脸识别，所以我可能直接应该将人脸识别这一具体的功能拉入编排而不是把身份认证这个大的构件拉入编排

答：可以的，这三个功能要不要做到一起是可以根据实际情况来的，不是非要整合不可

问：由于人脸识别有个身份证号的输入字段，所以我在想是不是需要在编排的时候，从他的上游构件的输出的一个身份证号直接映射到这个人脸识别的身份证号的输入字段上

答：逻辑上来讲，你可以给这个功能单独设计构件，这样业务模型在组合上表意也会更明确。这个就是看业务需求的实现顺序了，先输入身份证再验证人脸，或者是上一个服务已经读取了身份证再拉起人脸，那都是可以从上游传过来的。

问：但这样成本有点高啊，人脸，短信，银行卡是三种认证方式，感觉应该是归类组成为一个身份认证的构件，这三个要是单独都一个构件的话感觉有点小。。。而且我们规划身份认证这个构件的时候是打算升级为微服务的。。

答：这倒不完全是成本问题，所以为啥说落地要灵活呢，这是根据需要判断的。如果升级为微服务其实编排时就是一个构件直接拉入，你也就不用纠结了。

问：其实也不一定是微服务吧，可以以一种jar包的形式拉入编排也是可以的吧？

答：那就代表逻辑上不是一个微服务，你只是“处理”到了一起

问：我记得您在书上说的，可以是一个微服务，也可以是soa中的服务。我们原来设计就是一个身份认证直接拉进去编排，后来发现大部分都是人脸识别这类认证方式比较多，其他两类很少，就直接拆开了。

答：这是没问题的

问：我现在也不大想去做字段上下游的映射了，打算做个顺序的编排，以及包含一些分支跳转。。让业务系统来做适应性改造，适应产品工厂的动态变化

答：所以这是个业务和技术深入协商的问题，并非单一标准的问题，经过充分沟通和尝试，一定能找到合适的解，再基于这个解，保持业务和服务的准确映射。

问：明白了！