参考资料：
https://www.infoq.cn/article/an-informal-discussion-on-architecture-part01
https://www.infoq.cn/article/an-informal-discussion-on-architecture-part02
https://www.infoq.cn/article/an-informal-discussion-on-architecture-part03
https://www.infoq.cn/article/an-informal-discussion-on-architecture-part04
https://www.infoq.cn/article/an-informal-discussion-on-architecture-part05
https://www.infoq.cn/article/an-informal-discussion-on-architecture-part06
架构实际上解决的是人的问题，都是以人的认识为主体去讨论的，解决的都是人的问题，任何没有具体申明的部分都隐含这个背景。“相”实际上代表是这个作用，名是来标识这个作用，用来交流的。
做好结构所首先必须具备的能力，就是能够正确的认识概念，能够发现概念背后所代表的问题，进而才能够认识目标领域所需要解决的问题，这样才能为做好架构打好基础。
作为我们大部分时候是要去解决别人的问题，“别人”是谁，是值得好好思考的。只有真正明白是谁的问题，才能够真正完成自己的任务，真正把自己的问题解决掉，而不是反过来。架构师要有自觉，发现问题比解决问题来得更加重要。
当明白了问题的主体，我们才可能真正的认识问题是什么。因为问题的主体是问题的隐含边界，边界不确定下来，问题就是不确定的。一旦确定了主体，剩下的就是去搞明白主体有哪些问题。这个就比较直接了，常用的方式就是直接面对主体进行访谈，深入到主体的工作生活当中，体验并感受这些问题，甚至通过数据的反馈来定位问题。
为什么要切分？
- 某个或者某些利益相关人负载太重。
- 时间上的负载太重。
- 空间上的负载太重，本质上还是时间上的负载太重。
- 某个或者某些利益相关人的权利和义务不对等。
切分就要有几个原则：
- 必须在连续时间内发生的一个活动，不能切分。
- 切分出来的部分的负责人，对这个部分的权利和义务必须是对等的
- 切分出来的部分，不应该超出一个自然人的负载。当然对于每个人的能力不同，负载能力也不一样，需要不断的根据实际情况调整，这实际上就是运营。
- 切分是内部活动，内部无任怎么切，对整个系统的外部应该是透明的。如果因为切分导致整个系统解决的问题发生了变化，那么这个变化不属于架构的活动。当然很多时候当我们把问题分析的比较清楚的时候，整个系统的边界会进一步的完善，这就会形成螺旋式的进化。但这不属于架构所应该解决的问题。进化的发生，也会导致新的架构的切分。
总结一下
- 架构的切分的导火索是人的负载太重。
- 架构的切分实际就是对 stakeholder 的利益进行切分或合并，使得每个 stakeholder 的权责是对等的，每个 stakeholder 可以为自己的利益负责。
- 架构切分的最终结果都会体现在组织架构上，只有这样才能够让架构落地并推进。
- 架构切分的结果一定是一个树状，这也是为什么会产生分层。层数越多沟通越多，效率越低，分层要越少越好。尽可能变成一颗平衡树，才能让整个系统的效率最大化。
软件的本质，其实就是通过把人类的日常工作生活虚拟化，减少成本，提升单个人员的生产力，提升人类自己的利益。软件工程师的职责在这个浪潮中，不堪重负，自然而然就分拆为不同的角色，形成了一个独特的架构体系。这一切的背后，仍然是为了提升人类自己的利益，解决人类自己的问题。
分析问题：
1 虚拟化业务需要完成这些事情
2 代码如何运营，需要完成这些事情
3 如果分成不同的角色来完成这些事情，就需要一个组织架构来组织代码的编写和运营，需要做哪些事情
什么是软件架构呢？
- 软件因为流量增大而分拆成不同的运行单元，在不同的机器上部署所形成的架构，属于软件架构。
- 每个运行单元为了让不同角色的人，比如前端，业务，数据存储等能够并行工作，所分成的代码架构，也属于软件架构。
所以当我们说软件架构的时候，我们一定要讲清楚，究竟说的是部署的架构，还是代码的架构。软件架构的落地，需要软件的组织架构和流程来保障，离开了这个，软件架构是一句空话。
另外很多人讲，架构是进化出来的。架构实际上是在量不断的增大，超过了单台服务器的容量，逐渐的分拆，同时导致超过单个人员的能力，工作人员不断的增多，工作内容不断的分拆形成的。这本身就是架构的意义所在。不管怎么分拆，所达到的目标没有任何变化，就是完成业务在计算机中的虚拟化。