一、什么是解决方案层
领域层提供原子服务，解决方案层基于原子服务进行封装，来表达更加复杂的业务含义。
二、谁来封装解决方案层
如上图所示，解决方案层可能代码不会复杂，聚合一下几个领域层的原子服务，然后向上游系统提供一个稍微复杂一点的、有业务含义的能力。
根据以往的开发经验，一般业务需求极少有某个领域层能单独满足。都是需要联动一些别的领域共同完成服务，所以解决方案层是普遍存在的。
但是，一般领域层都是有明确负责人的，大家以家庭联产承包责任制的模式耕耘着自己的领域，一般维护的都很好。而解决方案层却像一个皮球被踢来踢去，没有很好的责任划分。上游的同学实现也行，下游的同学实现也行，单独拉个解决方案团队来实现也行。所以解决方案层成了一块无序之地。
因为无序，所以解决方案层实现的千奇百怪
策略一，谁要用谁封装
如上图所示，
这个是一种比较典型的解决方案层实现方式，谁要用谁自己封装
这种方式使解决方案丰富多彩，解放了下游域，让下游各个领域专注打磨自己的领域。
初看这种模式是好的，但是时间久了，系统版本多了，会发现很多问题：
1、各个下游域不知道自己的接口在被别人怎么用
这使得各个域想收回一些接口的时候变得非常困难。
如上，锤头域想停产3号锤头时，会发现，3，4，7号锤子都用不了了。因为是谁用谁封装，一般情况下锤头域根本不知道有3，4，7号锤子的存在。
从我入职到现在，大概每半年就会有下游发起一次梳理。梳理大家的系统用了他们哪些接口，使用场景是什么。梳理完我们也不能保证当时梳理全了，也不能保证再过段时间是不是有新的用法。最近的一次梳理是最近的大禹治水项目，全域拉齐了去治理这个问题，沟通成本特别大。
2、接口的运维成本特别大
软件系统是需要持续运维的，系统在运行的过程中会出现各种各样的异常。
如上图，8个锤子，就得有8个人力去运维这这个锤子，不管是锤子出问题还是手柄出问题，这8个人都得跟进去看，得去定位自己运维的锤子是哪里出了问题，然后得拉皮条似的拉上对应域的同学去解决。就像中间商似的，赚了一堆工单，自己又解决不了。这个对人力资源的浪费是巨大的。
目前集团的一大方向是降本增效，我以自己的工作经验来预估一下这里面的人力使用情况。
假设：锤子每天出16个问题，锤头域导致的问题12个，手柄域导致的问题4个
锤子定位问题需花费1单位人力，跨域沟通得花费1单位人力，对应域解决这个问题花费1单位人力。
这样计算下来，这种模式运维工作量为：16*1（定位问题）+12*1+4*1（跨域沟通）+12*1+4*1（解决问题）=48单位人力
策略二，拉一个解决方案团队来封装
如上图所示，
拉一个专业的解决方案团队来封装可以做到对下游域无感，减轻上游域负担。
而且专业的团队能提供专业的解决方案，可以以全域的视角汇总各个上游的使用情况，挺高解决方案层的复用率，可能会发现4个锤子就能解决所有域对锤子的需求了。
1、解决方案团队能知道各个上游域的接口被怎么用
这样下游域想收回一些接口的时候，与解决方案团队沟通就行了。做一些兼容改造，可以做到让上游无感。
避免了半年一次的接口大梳理，减少沟通成本，各下游域的接口使用情况也能有个团队给出准确的结论。
2、接口的运维成本降低，解放上游域的运维工作
还是上面的情况，因为有专业的团队提供解决方案，可以使锤子更专业，理论上问题能减少
所以之前16个问题可能变成12个，锤头域导致的问题9个，手柄域导致的问题3个
这样计算下来，这种模式运维工作量为：12*1（定位问题）+9*1+3*1（跨域沟通）+9*1+3*1（解决问题）=36单位人力
3、脏活累活较多，成长性不高
这种模式有个问题就是解决方案团队会脏活累活较多，主要工作就是对接各个域的接口，处理各个域接口暴露出来的问题。一天到晚的处理各种工单。技术成长性不高，对阿里这种年轻的企业，可能没人愿意做，发展前景不高。
策略三，由能最大程度解释解决方案问题的域来封装
这个策略就是哪个域占有这个解决方案逻辑的大头，就由哪个域来封装。
依旧是上面的场景，锤子每天出16个问题，锤头域导致的问题12个，手柄域导致的问题4个。
对这种情况，最好的方案是锤头域封装锤子的解决方案。
1、下游大域能以较低的沟通成本完成解决方案的封装
比如锤头域，只用拉着手柄域对一下就能把这个锤子做出来。
而别的策略都是外人拉着锤头域、手柄域，三方沟通才能把锤子做出来。
而且锤头域做接口升级也特别便捷，即使手柄域要升级也只用找锤头域沟通就行。
2、接口的运维成本最低
还是类比上面的情况，理论上锤头域能提供比解决方案团队更专业的方案，但是对问题先不做减少了。
所以之前16个问题还是变成12个，锤头域导致的问题9个，手柄域导致的问题3个
因为解决方案就是锤头域提供的，所以节省了跨域沟通成本。
发现是自己域的问题时理论上是有buff加成的，能更快的解决问题，假设解决效率提高50%。
这样计算下来，这种模式运维工作量为：
12*1（定位问题）+3*1（跨域沟通）+9*1*0.5（锤头域解决问题）+3*1（手柄域解决问题）=22.4单位人力
3、下游域工作量会增加很多
这种模式唯一的问题就是下游域的工作会多很多，但是对全域来说这样解决方案更干净，对自己接口的掌控力更强。
像那种我只提供接口，你怎么用我不管的模式对运维是很不友好的。可能开发阶段这种模式很好，一锤子买卖，开发的时候能干干净净的。但是上游滥用你的接口同样会极大的增加你的运维工作量，如高并发，脏数据等等问题。
因此，对于那些需要持久运维的系统，选择这种策略也是合适的，你对上游的需求和调用量都有个了解，也能避免一些系统性风险。不要对异常问题抱有任何幻想，随着运维时间的变长，数据接入量的增加，系统的持续迭代，你想的到的，想不到的异常问题都会发生。
三、如何决策用哪种策略来封装解决方案
对于如何决策使用哪种策略来封装解决方案，这个就是一个很复杂的问题了，可能涉及人文、政治等等领域了。
但是我觉得作为一个纯粹的技术人，哪种策略能让整个团队减少人力资源，结构更加清晰化，这些还是能达成一些共识的。
对于运维工作量不多，接入数据量不多，组织结构简单，迭代也不频繁的系统来说，其实用上面哪种策略随意。
但是组织架构复杂的，得考虑到跨域沟通的成本会很高；系统迭代频繁的，得考虑到系统版本会很多，接口稳定性可能会差一点，可能时不时的需要做版本归一，导致一些接口不可用等；接入数据量大的，得考虑到出问题的量也会成正比的增加。
有些生活中的原则也是适用于系统架构的
1、拒绝中间商赚差价
域跟域之间的交互应尽可能的减少中间商赚差价。系统里面的解决方案层其实就是一个中间商，但是这个中间商如果没有一个很好的管理的话，就就会像现实中的黑中介一样，骗了上游骗下游，骗完了自己再跑路，留下一堆乱摊子。
如上策略一是很容易出现黑中介的，成为系统里面的毒瘤。毕竟大家自由封装的解决方案，都没注册个公司，哪天要治理都没个抓手，但是哪天你要是违约了，没准他就跳出来碰瓷了。
2、让能解决问题的人最快发现问题
组织结构大了之后，会存在的一个问题是，业务同学发现了问题之后不知道该找谁去解决，如现在我们经常会收到一些不是我们域的工单。我们的组织架构对业务来说是黑盒的，其实一个域对另一个域的组织架构也是黑盒的，这样就会让沟通成本变的特别高。
还是上面的例子，
策略一假设由8个域分别完成的封装，则需要构建一条8（上游域）*2（锤子、手柄）= 16的稳定的跨域沟通链路，才能让错误信息顺畅的流通。
策略二因为是一个团队完成，所以构建一条1（解决方案团队）*2（锤子、手柄）= 2 的稳定的跨域沟通链路，就可以让错误信息顺畅的流通。
策略三只需要构建一条1（锤子）*1（手柄）=1 的链路，就能让错误信息顺畅流通。
需要的稳定链路越多，错误信息的流通卡点越多，错误信息传递到能解决的人手里的时效越长。因此运维这个链路消耗的人力成本也越高。
3、赢者通吃原则
如果选择的策略三，我们让哪个域来封装这个解决方案。
这个时候，我觉得可以适用赢者通吃原则。哪个域可以最大程度的解释这个解决方案，就由哪个域来封装这个解决方案。
这样做的好处是，能最大程度的减少沟通成本，运维成本。
还是上面的问题，锤子域每天出16个问题，锤头域导致的问题12个，手柄域导致的问题4个
如果策略一和策略二，他们对这个解决方案的解释程度是0，所以跨域沟通成本是16。
如果锤头域来封装这个解决方案，只有4个问题需要跨域沟通，其成本只有4。
如果手柄域来封装这个解决方案，则有12个问题要跨域沟通，其成本为12。
四、总结
目前，整个CTO线的一大目标就是降本增效。降低一些低效的人力消耗也是降本增效的一个方案。
对于业务中台，里面很高的一个成本其实是沟通成本，之前有个文章写的很好，很系统的论述过这个问题《复杂组织下协作成本倍增的起因、影响及可能的解》。我们在做工单运维的时候其很多时间在判断这个工单是哪个域的，该转到哪里去，一个工单可能会经手很多道才能到正确的人手里。所以合理的分配解决方案层是可以让这个扭转路径变短的，减少一些陪跑的同学。
一些浅薄的建议，希望对大家有用，欢迎感兴趣的同学一起交流。
