以架构师的思维工作

首先我们熟悉架构师思维

抽象
分层
分拆（或划分职责）
建立内部流程
学会了技术并不代表能够解决问题

      架构师，首先，架构师的前提条件，那就是发现问题并提出有效解决方案处理问题的人，架构师一定拥有丰富的经验和技术，而且他是调整利益平衡利益的人。之后，从架构的角度写代码，核心是分层，将业务，技术，逻辑处理分成各自耦合度相对降低的层次，让软件的运营成本降至最低，而且利于维护。最后就是理清技术、业务和架构的关系了。技术是为了解决业务的问题而产生的，没有了业务，技术就没有了存在的前提。有了更好的技术，效率更差的技术就会被淘汰，一切都遵从人类的利益诉求—也就是业务。再者，在解决同一个业务的问题的前提下，更高效，更低成本的技术将代替其他技术。所以架构师应该承担起解决业务问题的角色，也需要具备识别技术采取技术相应的能力。

很多人会问，特别是做软件行业的，架构师是不是需要学习技术，甚至是学习语言？ 如果一个架构师还有这个困扰—就如问这个问题的人，说明目前还不具备做架构师的能力，或者说还不具备对自己领域–哪怕是技术领域–的自信，更别谈业务领域了。
因为技术和语言，都是用来识别和解决所服务的主体的权责，保护并提升所服务的主体的权利的。特别对于软件领域来说，必须明白软件本身是怎么回事，解决什么问题，还要解决软件所服务的对象的领域本身是怎么回事，解决什么问题，这就要求更高了。语言和技术应该是随手拈来才对，对于架构师这些都是工具。学习技术和语言，如果明白了这些技术和语言要解决的是谁的问题，什么问题，学起来是非常快，非常容易的。
同样，采用哪个技术或者语言，只要某个技术或语言所解决的问题的主体，以及所解决的问题，和自己所面对的问题的主体和这个主体要解决的问题，这两者是匹配的，那么这个方案是成本是最低的，所采用的技术或者语言就是靠谱的。没有趁手的工具或语言的情况下，自己设计一个也不难，因为很清楚自己要什么。要不要自己做，无非是一个成本问题，也就是利益问题。并且从这个思路下去，选择的工具和语言肯定都是最简单的，成本是最低的。因为架构毕竟解决的还是人的利益问题，成本越低越好，这个成本当然是长期总体成本，不是眼前的短期成本。

从架构的角度看如何写好代码
当我们有了好的架构，那就需要考虑如何将架构落地，而这个时候，代码就显得无比重要了！千万不要让代码成为架构扩展的瓶颈。
软件架构实际上包括了：代码架构，以及承载代码运行的硬件部署架构。实际上，硬件部署架构最终还是由代码的架构来决定。因为代码架构不合理，是无法把一个运行单元分拆出多个来的，那么硬件架构能分拆的就非常的有限，整个系统最终很难长的更大。
所以我们经常会听说，重写代码，推翻原有架构，重新设计等等说法，来说明架构的进化。这实际上就是当初为了完成任务，没有充分思考所带来的后果。这也并不是架构进化的事情，而是个人对问题领域的逐渐深入理解的过程。所以有必要再讨论一下，代码的架构应该是怎样的。

理清技术、业务和架构的关系
在很多人的概念里面，架构和技术实际上是等同的。学会了几种技术，就认为自己是架构师了，甚至是学习的技术越多，就觉得自己的水平越高。这样实际上是对自己很不负责任的。

要知道任何技术都是为了解决某种问题而存在的，学会了技术，并不代表自己能够解决问题，这一点非常的重要。

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

也就是说：
业务目标是为了取火，钻木取火这个技术的出现解决了这个问题。
钻木取火的效率不高，影响了业务（取火）的效率，就有了进一步改进的动机，改进转动木棍的方式，产生了弓弦转动木棍的技术。

技术与架构，以及与业务之间的关系
技术总是在人类解决对业务的要求不断提高的情况下产生，目的也是为了获取更大更好的利益。所以：
技术是为了解决业务的问题而产生的，没有了业务，技术就没有了存在的前提。
有了更好的技术，效率更差的技术，就会慢慢的被淘汰，消失，一切都遵从人类的利益诉求–也就是业务。有人会问，不用钻木取火了，但是弓弦加速转动木棍还可以用啊？ 没错，因为弓弦转动木棍这个技术，不是来生火的，是用来加速木棍转动的，所解决的问题不一样。但是两种不同的技术，合理结合起来，会更好更有效率的解决业务问题。
所以技术与技术之间，有两种关系：
在解决同一个业务问题的前提下，更高效，更低成本的技术，会淘汰低效，高成本的技术。这是人类利益诉求所决定的。
一般刚开始解决根本问题的技术（钻木取火）的效率是比较低的，只是把不可能变成了可能（从这一点上来说，技术才是业务的enabler）。然后就会有提高效率的需求出现，要求改进这个技术。这个技术的低效率部分就会被其他人（或者技术发明人自己）加以改进，这部分就会形成新的技术。
当关系2发生的时候，这个地方必定会形成一个切分，新技术会通过某种方式和原有的技术连接在一起形成一个整体，让这个新的技术可以和原有技术共同工作，使得原有的技术可以用更高的效率解决问题。因为要解决的主要问题（生火）并没有发生改变，分拆所形成的是一个树状的结构。
按照前面的架构定义，这个时候其实已经产生了架构。也就是说，一般是先有技术，才会有架构。这些其他技术（弓弦拉动木棍），是从直接解决问题的初始主要技术中分拆出来形成的，并通过树状结构和主要技术（钻木取火）组合在一起。在解决主要问题（生火）之后，再开始逐渐的分拆为更为细粒度的技术（弓弦转木棍）。
而这个细粒度的技术（弓弦转动木棍）往往不会和业务的主要目标（生火）发生直接的关系。不同的技术，通过树状结构，组合在一起，形成了一个完整的架构解决方案，共同完成业务的目标。这就是技术，业务和架构之间的关系。很多人把这个过程称为架构的进化，我更愿意把这个过程称为技术的进步所导致的新的架构分拆，因为这个过程内在的动力，更多的是来自技术对解决业务问题的解决。

技术人员和业务人员的关系
为什么技术人员总是和业务人员发生冲突呢？ 这是因为技术人员很多时候关心的技术，和业务的主要目标往往不是直接对应的，业务也是负责某一部分的业务，也不是和业务的主要目标直接对应的，都是树的分支节点（上文已经解释了为何会发生这种情况）。只有直接解决业务问题的那个技术（或业务）–树的根节点–会和业务直接相关。所以一旦产生冲突，一般必须两个根节点（一般都是领导）碰面才能解决问题，就是这个原因–他们都知道业务主要目标。这也是为什么下层无法理解上层，而上层都喜欢下军令状，要求下层执行。人只有尽量去理解上层的问题才能做下层的分拆。
在软件行业，这个根节点技术就是软件。这也是为什么架构师要认识什么叫软件，软件解决谁的问题，什么问题，软件本身又是怎么分拆的，才能够更好的组合不同的技术，完成业务的目标。而软件里面和业务直接相关的，只有Business Domain这一部分。
用人来打比方，Business Domain相当于人的大脑，而Service，Repository，Glue Code等部分所采用的技术，全部都是计算机自己领域的技术，都是为了能够让程序跑起来，相当于人的四肢。我们大部分开发人员的工作主要专注于四肢部分。我们真正应该投入的是大脑部分。因为大脑能够决定四肢长什么样，而不是反过来。很多架构师、技术人员主要专注于计算机相关的技术，忽略了业务本身，甚至看不起业务，这也是为什么技术总是和业务冲突的原因。
架构师应该承担起解决业务问题的这个角色来，专注于Business Domain和软件本身的架构，让技术人员致力于为业务在计算机中跑起来而努力。只有把这两者很好的结合起来，才能更好地完成业务的目标，才会让软件更好地服务于大家。最终一定会得到一个很好的软件架构，令软件开发团队和业务部门都能够很好地开展工作并降低成本。