架构漫谈（九）：理清技术、业务和架构的关系

上篇：架构漫谈（八）：从架构的角度看如何写好代码

　　某天和朋友吃饭正好聊到这个话题。做为架构师或者作技术的人，在开发软件时，咱们基本上就是在扮演上帝的角色：咱们不但要建立出一个个的程序，还要让这些程序可以脱离咱们在硬件上独立运行，以便为这个程序所服务的群体提供服务。当这个程序出现问题甚至bug的时候，咱们还得扮演牧师的角色去修复这些问题。这不正是一个程序的社会吗？ 和人类社会的演变何其类似！那么咱们天然也可以拿人类演变的历史来指导软件开发工做，以免再经历一次像人类演变发展那么痛苦的过程了。由此咱们也能够看出，架构师和程序员们都在扮演着多么重要的角色，若是还在解决本身的问题，怎么扮演好上帝这个角色？

　　在软件设计开发的过程当中常常会看到，不少所谓的架构讨论实际上只是在讨论某种技术。在不少人的概念里面，架构和技术其实是等同的。学会了几种技术，就认为本身是架构师了，甚至是学习的技术越多，就以为本身的水平越高。这样其实是对本身很不负责任的。要知道任何技术都是为了解决某种问题而存在的，学会了技术，并不表明本身可以解决问题，这一点很是的重要。学会的技术的多少，所带来的差异只是本身解决问题的手段多了罢了。可是手段多了就必定是好事吗？ 不少时候，学习的技术越多，越不知道采用哪一种技术好，所谓“乱花渐欲迷人眼"。

　　还有另外一种很广泛的观点：技术人广泛看不起业务，认为技术更高端，而业务过低端，而且业务每每喜欢给技术挖坑。业务则以为技术眼光高，可是实际解决不了问题，老是理解有误差，可是又迫不得已，由于本身不会。

　　本篇文章尝试从这里入手，分析一下这三个概念到底有什么关系，咱们应该怎么处理业务、技术还有架构的关系。

　　什么是技术

　　当咱们一无全部，或者什么都不会的时候，这个时候其实是没有技术的。就比如人类在最先期，什么都得用本身的双手来干活。一旦咱们在平常生活中无心间发现某些规律的时候，咱们就能够经过创造条件，让这个规律重复的发生。经过人为创造条件，让指定的规律按照人类的意愿发生，这就是技术。

　　好比取火，最先人类只能靠打雷等天然现象产生火。取火其实就是一个业务目标，要解决的是人类本身的问题，这就是业务，实际就是人类的利益。这个时候人类没有生火的技术，只能靠不断的加木材，保持火不熄灭。后来人们发现了钻木取火：只要用一个干的木棍，在另外一个干木表面快速的转动，就能够生火。这个办法让人类能够自行创造火源，就产生了钻木取火的技术。

　　可是双手快速转动木棍钻木取火，并非全部人都可以作获得的，须要不少力量和速度，对人的要求过高。为了解决快速转动的问题，就有人采用弓弦来提高木棍转动的速度。

　　也就是说：

1. 业务目标是为了取火，钻木取火这个技术的出现解决了这个问题。

2. 钻木取火的效率不高，影响了业务（取火）的效率，就有了进一步改进的动机，改进转动木棍的方式，产生了弓弦转动木棍的技术。

　　技术与架构，以及与业务之间的关系

　　技术老是在人类解决对业务的要求不断提升的状况下产生，目的也是为了获取更大更好的利益。因此：

1. 技术是为了解决业务的问题而产生的，没有了业务，技术就没有了存在的前提。

2. 有了更好的技术，效率更差的技术，就会慢慢的被淘汰，消失，一切都听从人类的利益诉求——也就是业务。有人会问，不用钻木取火了，可是弓弦加速转动木棍还能够用啊？ 没错，由于弓弦转动木棍这个技术，不是来生火的，是用来加速木棍转动的，所解决的问题不同。可是两种不一样的技术，合理结合起来，会更好更有效率的解决业务问题。

　　因此技术与技术之间，有两种关系：

1. 在解决同一个业务问题的前提下，更高效，更低成本的技术，会淘汰低效，高成本的技术。这是人类利益诉求所决定的。

2. 通常刚开始解决根本问题的技术（钻木取火）的效率是比较低的，只是把不可能变成了可能（从这一点上来讲，技术才是业务的enabler）。而后就会有提升效率的需求出现，要求改进这个技术。这个技术的低效率部分就会被其余人（或者技术发明人本身）加以改进，这部分就会造成新的技术。

　　当关系2发生的时候，这个地方一定会造成一个切分，新技术会经过某种方式和原有的技术链接在一块儿造成一个总体，让这个新的技术能够和原有技术共同工做，使得原有的技术能够用更高的效率解决问题。由于要解决的主要问题（生火）并无发生改变，分拆所造成的是一个树状的结构。

　　按照前面的架构定义，这个时候其实已经产生了架构。也就是说，通常是先有技术，才会有架构。这些其余技术（弓弦拉动木棍），是从直接解决问题的初始主要技术中分拆出来造成的，并经过树状结构和主要技术（钻木取火）组合在一块儿。在解决主要问题（生火）以后，再开始逐渐的分拆为更为细粒度的技术（弓弦转木棍）。

　　而这个细粒度的技术（弓弦转动木棍）每每不会和业务的主要目标（生火）发生直接的关系。不一样的技术，经过树状结构，组合在一块儿，造成了一个完整的架构解决方案，共同完成业务的目标。这就是技术，业务和架构之间的关系。不少人把这个过程称为架构的进化，我更愿意把这个过程称为技术的进步所致使的新的架构分拆，由于这个过程内在的动力，更多的是来自技术对业务问题的解决。

　　技术人员和业务人员的关系

　　为何技术人员老是和业务人员发生冲突呢？ 这是由于技术人员不少时候关心的技术，和业务的主要目标每每不是直接对应的，业务也是负责某一部分的业务，也不是和业务的主要目标直接对应的，都是树的分支节点（上文已经解释了为什么会发生这种状况）。只有直接解决业务问题的那个技术（或业务）—— 树的根节点 —— 会和业务直接相关。因此一旦产生冲突，通常必须两个根节点（通常都是领导）碰面才能解决问题，就是这个缘由——他们都知道业务主要目标。这也是为何下层没法理解上层，而上层都喜欢下军令状，要求下层执行。人只有尽可能去理解上层的问题才能作下层的分拆。

　　在软件行业，这个根节点技术就是软件。这也是为何架构师要认识什么叫软件，软件解决谁的问题，什么问题，软件自己又是怎么分拆的，才可以更好的组合不一样的技术，完成业务的目标。而软件里面和业务直接相关的，只有Business Domain这一部分。

　　用人来打比方，Business Domain至关于人的大脑，而Service，Repository，Glue Code等部分所采用的技术，所有都是计算机本身领域的技术，都是为了可以让程序跑起来，至关于人的四肢。咱们大部分开发人员的工做主要专一于四肢部分。咱们真正应该投入的是大脑部分。由于大脑可以决定四肢长什么样，而不是反过来。不少架构师、技术人员主要专一于计算机相关的技术，忽略了业务自己，甚至看不起业务，这也是为何技术老是和业务冲突的缘由。

　　架构师应该承担起解决业务问题的这个角色来，专一于Business Domain和软件自己的架构，让技术人员致力于为业务在计算机中跑起来而努力。只有把这二者很好的结合起来，才能更好地完成业务的目标，才会让软件更好地服务于你们。最终必定会获得一个很好的软件架构，令软件开发团队和业务部门都可以很好地开展工做并下降成本。

　　从新发明轮子

　　当现有已经存在不少技术，而这些技术却和咱们所要解决的问题并非那么直接对应的时候，咱们就须要有意识的组织和识别不一样的技术，来实现业务的目标。这个时候组织的方式有不少种，其中成本最低的方法就是按照要达成的目的和当前的问题，从上到下进行架构分拆。分拆出来的更细粒度的问题，分解到不一样的人来进行解决，就造成了业务架构和组织架构。解决这些问题就须要组合不少不一样的技术，那么应该采用哪些技术？仍是本身重头实现一个？ 本身实现一个——这就是不少人所谓的从新发明轮子。如下试着分析一下：

1. 当技术所解决的问题和分拆出来要解决的问题，彻底匹配的时候，这是最完美的。好比须要提供web要访问的service，不少MVC的framework就能够很好的知足这一点。而这个时候若是非要本身实现一个，颇有可能就是从新发明轮子。

2. 当技术所提供的能力远远超过须要解决的问题时，每每掌握技术和维护技术会成为瓶颈。由于越复杂的技术，成本越高。若是本身实现一个仅仅是解决当前问题的方案，可能成本反而更低。这也是为何不少大型的互联网公司不断地开源出来本身的技术的缘由。而这些技术对于咱们来讲是否适用？他们本来是用来解决谁的问题的？什么问题？若是不清楚这些，就冒然采用，可能会致使更高的成本。

3. 当技术所提供的能力和咱们所要解决的问题部分匹配时，仍是要当作本。好比当咱们须要一个锤子的时候，手边正好没有，可是却有一只高跟鞋，勉强也能够替代锤子。可是长期来看，这么用不划算，由于高跟鞋的价格比锤子高不少，耐用性差不少，维护成本也高不少。

　　因此，准确识别采用什么技术的能力，也是架构师所要具有的能力之一。考虑的主要因素也是长期的成本和收益。