通过对王概凯写的《架构漫谈1-9》https://www.infoq.cn/profile/1279517?menu=publish#menu-trace的阅读，总结出以下几点：
（一）什么是架构？
1、根据要解决的问题，对目标系统的边界进行界定。
2、并对目标系统按某个原则进行切分。切分的原则，要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间。
3、并对这些切分出来的部分，设立沟通机制。
4、根据3，使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。
（二）为什么会产生架构？
由于不同的社会分工加上角色分配，建立起不同部分的有机结合，整合起来，达到这个整体的利益最大化，就是把一个整体（完成人类生存的所有工作）切分成不同的部分（分工），由不同角色来完成这些分工，并通过建立不同部少时诵诗书或分相互沟通的机制，使得这些部分能够有机的结合为一个整体，并完成这个整体所需要的所有活动，这就是架构。因为社会分工的不同，每个人的能力有限，人的要求、目的的更高要求，如何在不同的部分做合理的分配、从而提高工作的效率。用作者的话就是架构就是指人们根据自己对世界的认识，为解决某个问题，主动地、有目的地去识别问题，并进行分解、合并，解决这个问题的实践活动。
（三）认识概念？（以人的认识为主体讨论）
“概念”是人认识这个世界的基础，是人认识这个世界并用来沟通的手段，自然概念的认识就非常的重要。
每个概念实际上所解决的，还是人遇到的某个特定的问题，我们把解决问题的解决方案，给定了一个名字，这个名字就是对应的某个特定的概念。比如杯子的概念就是解决“人需要一个可单手持握，但是希望避免直接接触所盛物体”这个问题的。
（四）认识问题？
我们大部分时候过于关注解决问题，急于完成自己的工作，而不关心“真正的问题是什么
当我们去解决一个问题的时候，一定要先把问题搞清楚。
如何识别问题？
·前提就是要搞清楚：是谁的问题，即搞清楚问题的边界。
（五）架构的切分？
很多时候问题的产生都是因为沟通的误解，或者主观上有很多不必要的利益诉求导致的。但是总还有一部分确实是有问题的，需要做调整，那么就必须要有所动作，做相应的调整。这个调整就是架构的切分。
1.必须在连续时间内发生的一个活动，不能切分。
2.切分出来的部分的负责人，对这个部分的权利和义务必须是对等的。
3.切分出来的部分，不应该超出一个自然人的负载。
4.切分是内部活动，内部无任怎么切，对整个系统的外部应该是透明的。
5.确保我们不能违反人性，因为维护自己的利益。所有的架构分拆，都应该是形成树状的结果，不应该变成有向图，更不应该是无向图。
实际上切分的过程就是建模的过程，每次对大问题的切分都会生成很多小问题，每个小问题就形成了不同的概念。
—>架构的切分的导火索是人的负载太重。
—>架构的切分实际就是对 stakeholder 的利益进行切分或合并，使得每个 stakeholder 的权责是对等的，每个 stakeholder 可以为自己的利益负责。
—>架构切分的最终结果都会体现在组织架构上，只有这样才能够让架构落地并推进。
—>架构切分的结果一定是一个树状，这也是为什么会产生分层。层数越多沟通越多，效率越低，分层要越少越好。尽可能变成一颗平衡树，才能让整个系统的效率最大化。
软件一直以来的动力，始终都是来模拟人和这个社会的。
（六）如何成为一个好的架构师？
1.能够正确的认识概念，能够发现概念背后所代表的问题及人的利益，进而才能够认识目标领域所需要解决的问题，这样才能够为做好架构打好基础。
2.找出问题的主体是做架构的首要问题。即解决一个问题之前，一定要先把问题搞清楚，搞清楚目标问题是谁的问题，架构师都要有这个自觉：发现问题永远都比解决问题来的更加重要。
3.能将大问题切分成若干小问题
4.架构师还必须要明白，所给出的解决方案 -- 架构的分拆、合并方案，只有让问题的主体的权责对等，才能够真正的解决别人的问题。
5.要有自信
6.架构师是要去平衡别人的利益，甚至会调整别人的利益的。
7.具有准确识别采用什么技术的能力
8.架构师应该承担起解决业务问题的角色，将技术和业务两者很好的结合起来，让软件更好地服务于人。
附：怎么处理业务、技术还有架构的关系
1.技术是为了解决业务的问题而产生的，没有了业务，技术就没有了存在的前提。
2.有了更好的技术，效率更差的技术，就会慢慢的被淘汰，消失，一切都遵从人类的利益诉求 ——也就是业务。
3.在解决同一个业务问题的前提下，更高效，更低成本的技术，会淘汰低效，高成本的技术。
4.技术是不断地在更新和优化。
5.不同的技术，通过树状结构，组合在一起，形成了一个完整的架构解决方案，共同完成业务的目标。
小收获：（从架构的角度看如何写好代码）
软件架构实际上包括了：代码架构，以及承载代码运行的硬件部署架构。实际上，硬件部署架构最终还是由代码的架构来决定。想快速的完成代码工作，就要克服自己对时间的恐惧，真正的去研究业务的问题，相关 stakeholder 的利益，把这个变成我们的习惯。写代码的时候让该出现逻辑的地方出现逻辑，让不该出现的地方不能出现。一旦不该出现的地方出现了逻辑，那么要马上意识到，这个地方是一个坑，这个问题一定和业务的分析不透彻有关系。