***本文源自一篇读者来信，是关于业务架构实施的问题，而且问题很有共性，所以我征得了读者的同意，保留原文并将我的答复以写在方括号中进行分享，以方便大家结合问题和问题的语境来阅读。有些圆括号中没有涂红的是读者来信内容，别读混了***
付老师，这个问题可能比较细节：
关于业务任务和业务构件的关系
一个业务任务是否应该和一个业务构件对应？【可以这样设计，书中讲的毕竟是个设计逻辑，不过，从便于组合的角度来讲，还是建议一对一】我理解这里面可能和业务任务和业务构件的粒度有很大关系，举个我们银行的产品例子：我们有个线上贷款产品，客户在线上申请之后就会触发线下人工核实，人工核实分成客户经理和支行行长两个岗位，客户经理可以维护所有信息，而支行行长只能审查不能修改，最后可以同意或者拒绝。客户经理所维护的工作项包括几个：
1）核实：通过电话和客户核实信息（电话核实）、到现场核实客户信息（现场核实）；
2）采集影像：采集客户资料影像；
3）确认信息：确认客户经营信息、确认客户征信信息、确认客户历史贷款信息；
4）维护岗位意见；
这就带来几个问题：
（1）假如把客户经理和支行行长分别当作是一个业务任务，即客户经理维护业务任务和支行行长复核业务任务，那么按照这个粒度的话感觉有点大【我们以前的经验是把维护和复核分开，复核是单独的任务，因为多数复核是权限上的差别而没有业务逻辑差别】，这样任务好像不大好进行复用和编排了，因为一个任务里面就包含了上面客户经理的从1）到 4）需要操作的事情。
（2）假如把上面客户经理的从1）到 4）需要操作的事情拆成多个任务的话，比如电话核实任务、现场核实任务、采集影像任务等，是不是合理些？因为别的贷款产品也会有电话核实、现场核实这里一样的业务任务，这样基于业务任务级的复用是不是更好一些？【从感觉上看，核实本身是一个任务，这个任务中可以采用现场、电话两种方式，可能涉及录音或影像采集，因此，应该可以考虑成一个任务，因为需要业务人员输入到界面上的信息可能是近似甚至相同的，涉及到录音、录像作为附件，也就是核实任务产生核实记录，这条记录可能关联到两个非结构化的文件，如果其他业务经过标准化之后也能这么设计，那就是可以统一的流程了，如果不能实现标准化，就得拆分成多个构件了】
（3）业务任务应该是需要一个或者多个业务构件来对应实现的吧？也就是说业务任务是操作，我需要一个或者多个业务构件来实现我的这个操作，是不是这个概念？【从逻辑上来讲，构件是业务任务和业务数据的逻辑组合，也就是尽量一对一的，需要多个构件执行的就相当于任务流了，应该是多个构件组合的，如果把构件当成原子单位就好理解些了，虽然实操上不排除出现一些不那么干净的切分，但是不妨碍按照这个去思考整体逻辑，什么样的设计都会有例外出现，不要对例外太纠结，因为随着时间的发展可能会出现新的解决例外的机会】按照上面（1）的做法的话，就是一个大的客户经理的维护任务包括多个业务构件（电话核实任务、现场核实任务、采集影像任务等），按照（2）的做法的话就是：电话核实构件实现电话核实任务、现场核实构件现场核实任务、采集影像构件实现采集影像任务，哪一种更适合一些？【同前边的回答，这个取决于可标准化程度，所以为什么颗粒度是要业务和技术共商的，如果业务投入不够，技术上稳妥起见就会拆的细，但是实际上业务可能并不需要拆到这么细】
（4）假如我把构件的定义做成：电话核实构件、现场核实构件、确认客户经营信息构件、确认客户征信信息构件、确认客户历史贷款信息构件的话，前面两个我感觉属于高度类似，都是涉及到问题核实，后三个也属于高度类似，都是涉及确认客户信息的，那如果按照您之前说的“构件可以变成微服务”的话，总感觉电话核实构件、现场核实构件、确认客户经营信息构件、确认客户征信信息构件、确认客户历史贷款信息构件这些变成微服务的话太小了。。是不是可以这样：前面两个合并成一个构件，包括两个操作（电话核实、现场核实）【这个答案同前】，后面三个变成一个构件，包括三个操作（确认客户经营信息、确认客户征信信息、确认客户历史贷款信息）？【这个拆分也许跟业务的留痕要求有关，这些信息是存成一张大表，一个确认记录就可以，还是会被业务上分开检查，有不同的留痕要求，还是会在不同的时间操作不同的确认，还是尽管分开，但是只要关联到某一条确认记录进行，但是这样可能在以后库表有变动时产生些障碍。如果没有特殊业务限制，合并成一个就没问题，因为没有把不同步的变化原因合并进来】然后编排的时候，再选择这些构件下面的具体操作，是不是这样的？【三个还是一个其实都不影响编排，重要的是回答上边的问题，根据业务背景决定】
补充问题：
付老师，看到您的回答，我总感觉客户经理的维护假如当作一个任务的话感觉太大，因为客户经理需要做电话核实、现场核实、采集影像、确认信息、维护岗位意见等，这些事情其实很多流程都会用到，如果一个任务和构件是一一对应的话，总感觉应该把这些事情分别当作一个任务更合理，因为他们可以和电话核实构件、现场核实构件、采集影像构件、确认信息构件、维护岗位构件对应上。客户经理如果就还是只有一个维护任务的话，下面就变成了由多个构件（电话核实构件、现场核实构件、采集影像构件、确认信息构件、维护岗位构件）去组成？那就是一个任务对应多个构件了，这种情况是否允许？【对于后者来讲，这就是一个任务了，这时候就不必再纠结几个构件了。所以我说这东西怎么分都有理，但是最合适的方式是跟业务多做沟通，尤其是横向沟通，看看能标准化到什么程度，感觉上的大小不是问题，如果复用上就是一大坨都需要拿过去，那根本就不用纠结，就像一个没必要再拆的遗留系统，一个封装就处理了】
明白您的意思了，关键还是看业务如何使用，如果是整个维护任务都可以复用的话，就一个任务就可以，如果是多个这些都需要各自复用组装的话，再拆就比较合适。【是的，这就是为啥要业务和技术多沟通的原因，因为这些东西的拆分并没有绝对的规矩】
