（1）什么是架构：
首先把架构的概念讨论明白，然后在对架构进行分析才显得清晰有意义。架构是人类发展过程中，由被动地去认识这个世界，变成主动的去认识，并以更高的效率去改造这个世界的方法。由不同角色来完成这些分工，并通过建立不同部分相互沟通的机制，使得这些部分能够有机的结合为一个整体，并完成这个整体所需要的所有活动，就是架构。一切都是为了满足人的越来越高的需求，提升质量，减少时间，提高效率，并且让代码之间更加有机的进行沟通。
架构这个词在软件工程很早之前就已经出现了，在人类的早起大家的衣食住行都靠自己，不需要合作，这时候自然不需要架构。但是经过一段发展，人类发现合作的力量是巨大的，每个人都有自己所擅长的部分，在进行分工合作的时候产生的结果往往大于个人，这时候就产生了社会的架构。
从中可以看出架构产生的动力有五个：
1、由人执行；
2、每个人能力有限；
3、每个人时间有限；
4、目标期望高；
5、目标复杂。
对于架构的理解，大致总结如下：
1、根据要解决的问题，对目标系统的边界进行界定。
2、对目标系统按某个原则的进行切分，切分的原则，要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间。
3、对这些切分出来的部分，设立沟通机制。
4、使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。
而架构的产出物，自然就是对问题的分析，以及解决问题的方案：包括拆分的原则以及理由，沟通合并的原则以及理由，以及拆分，拆分出来的各个部分和合并所对应的角色和所需要的核心能力等。
（2）认识概念是理解架构的基础：
架构实际上解决的是人的问题，而概念是人认识这个世界的基础，自然概念的认识就非常的重要。
在做架构师的群体中，不谈抽象好像就不是一个合格的架构师。抽象这个词代表的含义，实际上是把不同的概念的相似的部分合并在一起，形成一个新的概念。这个里面问题很多：首先“相似的部分”在不同的人看来，并不一定那么相似；其次，抽象之后形成的是一个新的概念，和原来那个概念并不一样，所解决的问题也不一样。所以我们不能用抽象来定义一个事物，抽象实际上是一个分类的过程，完全是另一码事。
理解概念，对于理解这件事物来说十分重要。所以理解概念的背后用途，才能更好的解决问题。
根据架构的定义，要做好架构所首先必须具备的能力，就是能够正确的认识概念，能够发现概念背后所代表的问题，进而才能够认识目标领域所需要解决的问题，这样才能够为做好架构打好基础。之所以强调这个，是因为做架构的时候，很多时候都是在一个新的领域解决问题，必须要快速进入并掌握这个领域，然后才能够正确的解决问题。
（3）如何做好架构之识别问题：
做好架构首先需要做的就是：识别出需要解决的问题。
一般来说，如果把真正的问题找到，那么问题就已经解决了 80% 了，这个能力基本上就决定了架构师的水平。
如何去识别问题呢？所有的概念基本都有一个很大的问题，就是缺乏主语。而我们大家都心照不宣的忽略这个主语，沟通的时候也都以为大家都懂得对方说的主语是谁，结果大家都一起犯错误。识别问题的一个最大的前提就是要搞清楚：是谁的问题。这个搞清楚了，问题的边界也就跟着确定了，再去讨论问题才有意义。作为软件工程师或者架构师，我们大部分时候是要去解决别人的问题，“别人”是谁，是值得好好思考的。明白了问题的主体，这个主体就自然会带来很多边界约束。而从问题暴露的点，一点点去溯源查找，一定会找出来谁的问题，以及是什么问题。
我们要解决的问题不仅仅是表面上的工作，架构师需要完成的是隐藏的用户实际需要解决的问题。最主要的两个问题就是：1、这是谁的问题？ 2、有什么问题？架构师的主要任务大部分在于问题一上。
（4）如何做好架构之架构切分：
很多时候问题的产生都是因为沟通的误解，或者主观上有很多不必要的利益诉求导致的，但是总还有一部分确实是有问题的，需要做调整，那么就必须要有所动作，做相应的调整。
这个调整，就是架构的切分，所有的切分调整，都是对相关人的利益的调整。为什么这么说呢，因为维护自己的利益，是每个人的本性，是在骨子里面的，我们不能逃避这一点。
切分也需要有原则，这四个原则是：
1、连续时间内的活动不能切分；
2、权利义务对等；
3、不超出一个人的负载；
4、对外部透明。
关于架构切分总结如下：
1、架构的切分的导火索是人的负载太重。
2、架构的切分实际就是对 stakeholder 的利益进行切分或合并，使得每个 stakeholder 的权责是对等的，每个 stakeholder 可以为自己的利益负责。
3、架构切分的最终结果都会体现在组织架构上，只有这样才能够让架构落地并推进。
4、架构切分的结果一定是一个树状，这也是为什么会产生分层。层数越多沟通越多，效率越低，分层要越少越好。尽可能变成一颗平衡树，才能让整个系统的效率最大化。
（5）什么是软件：
软件的历史，实际上可以说是用机器模拟人的历史。在初期，软件使用二进制编写的，从硬件到软件，成本都非常的高。随着半导体技术的进步，硬件的成本越来越低，性能越来越高，甚至出现了摩尔定律：当价格不变时，集成电路上可容纳的元器件数目，约每隔 18-24 个月增加一倍，性能提升一倍。
软件工程师慢慢越来越多，开发软件的成本也越来越低。因此，人们越来越愿意把原来只有人才能做的事情，交给计算机来做。结果就导致软件越来越丰富，能够做的事情也越来越多，成本也越来越低。随着软件的规模的变大，做好一个软件也变得越来越难了。有些程序员熟练了之后，提高了自己的生产力，并发现还可以帮助别人写程序，慢慢软件就变成了一个独立的行业。
程序从早期由一个人完成，也逐渐变成了由很多不同角色的人共同合作来完成。
一开始是懵懵懂懂的去写软件，后来慢慢的就有意识的去切分，演变成了不同的架构。这个背后的动力也是一样的，就是提升参与的人的利益，降低成本。导火索也是软件工程师的任务太重，我们需要把很多工作拆分出来。拆分的原则也是一样的，如何让权责一致。所以软件开发就开始有分工了，行业知识和业务的识别。
软件的本质，其实就是通过把人类的日常工作生活虚拟化，减少成本，提升单个人员的生产力，提升人类自己的利益。
（6）架构要解决什么问题：
业务问题，计算机问题。
有两种架构：
1、软件因为流量增大而分拆成不同的运行单元，在机器上部署所形成的架构，属于软件架构。
2、每个运行单元为了让不同角色的人，比如前端，业务，数据存储等能够并行工作，所分成的代码架构，也属于软件架构。
（7）不要空设架构师这个职位，给他实权：
架构师必须是一个组织的领导人，有权利调动这个组织的架构，才能够更好的发挥架构师的作用，更好的把利益的调整落到实处。
如果一个人在工作中，只是致力于完成自己的工作，以做好自己的工作为主要目标，那么最多只能成为一个工匠，无法成为一个架构师。因为这个过程解决的还是自己的问题，并没有时间的压力，可以随意什么时候做完都可以。要成为架构师，必须要超越这个恐惧才能够看清楚，我们要解决的是别人的问题，不是自己完成工作的问题。因为仅仅是完成了自己的工作，也并不一定就解决了别人的问题。如果别人的问题没有解决 -- 即使我们认为自己的工作完成了 -- 我们的工作实际也没完成，因为我们工作是否完成，是别人说的算的，不是我们自己。
架构师是要去平衡别人的利益，甚至会调整别人的利益的。
（8）从架构的角度看如何写好代码：
当我们有了好的架构，那就需要考虑如何将架构落地，千万不要让代码成为架构扩展的瓶颈，尽量降低架构分拆的成本。
软件实际上是对现实生活的模拟，虚拟化。这是一个非常重要的前提，结合每个部署单元所承担的责任，可以明确的拆分为两个不同的责任：
1、表达业务逻辑的代码。
2、对用户提供访问并保存业务逻辑运行结果的代码。
业务逻辑：在软件代码中，不需缩进和计算的顺序调用，包括缩进的代码目的是 catch exception 的，都不算逻辑，除此以外都是逻辑。
（9）理清技术、业务和架构的关系：
技术：通过人为创造条件，让指定的规律按照人类的意愿发生，这就是技术。
技术与架构，以及与业务之间的关系：技术总是在人类解决对业务的要求不断提高的情况下产生，目的也是为了获取更大更好的利益。所以：
1、技术是为了解决业务的问题而产生的，没有了业务，技术就没有了存在的前提。
2、有了更好的技术，效率更差的技术，就会慢慢的被淘汰，消失，一切都遵从人类的利益诉求—— 也就是业务。
3、在解决同一个业务问题的前提下，更高效，更低成本的技术，会淘汰低效，高成本的技术，这是人类利益诉求所决定的。
4、一般刚开始解决根本问题的技术的效率是比较低的，只是把不可能变成了可能。然后就会有提高效率的需求出现，要求改进这个技术。这个技术的低效率部分就会被自己或他人加以改进，这部分就会形成新的技术。
为什么技术人员总是和业务人员发生冲突呢？ 这是因为技术人员很多时候关心的技术，和业务的主要目标往往不是直接对应的。只有直接解决业务问题的那个和业务直接相关的技术，即是树的根节点，才能解决问题。
架构师应该承担起解决业务问题的这个角色来，准确识别采用什么技术的能力，考虑的主要因素也是长期的成本和收益，让技术人员致力于为业务在计算机中跑起来而努力。
只有把这两者很好的结合起来，才能更好地完成业务的目标，才会让软件更好地服务于大家。最终一定会得到一个很好的软件架构，令软件开发团队和业务部门都能够很好地开展工作并降低成本。
