由于软件系统的复杂性，一般人很难非常清楚的将整个系统理的很清楚，所以才会出现架构视图的概念，而架构视图出现的一个主要动力或者原则就是：分而治之。
分而治之有两种类型
1. 按问题深度分而治之，即先不把问题想的那么深入，那么仔细，要浅尝辄止。例如定义各个模块之间的接口就属于这种，先不考虑如何实现接口，只是定义模块之间进行通信时的契约。
2. 按问题广度分而治之，即先不研究整个问题，而是研究问题的一部分，分割问题，各个击破。例如采取MVC架构进行开发时，每一层都属于一个比较深入的部分。
软件架构应该采取哪种方式？
所谓架构设计，是关于如何构建软件的一些最重要的设计决策，这些决策往往是围绕着系统分为哪些部分，各部分之间如何交互进行展开的。
所谓详细设计，则是针对每个部分的内部进行设计。
所以可以说对于架构设计，应该采取按照问题深度分而治之，关注的是系统的整体设计；而详细设计时应该采取按照问题广度分而治之，关注的是每个模块如何实现。
软件架构是团队开发的基础
一方面，架构从大局着手，就技术方面的重大问题作出决策，构造一个具有一定抽象层次的解决方案，而不是将所有细节全部展开，从而有效的控制了‘技术复杂性’。
另一方面，因为架构中包含了关于各元素应该如何彼此交互的信息，所以可以把不同的模块分配给不同的小组分头开发，架构在中间扮演‘桥梁’和‘合作契约’的作用。
架构应该设计到什么程度？
1. 由于项目不同、开发团队情况的不同，架构设计的程度也会不同。
2. 软件架构应该为开发人员提供足够的指导和限制。
什么是高来高去的软件架构？
高来高去的架构是指不能为开发人员提供足够的指导和限制的那种架构设计。
高来高去的架构的危害
1. 缺少来自架构的指导和限制，开发人员进入开发阶段后，会碰到很多问题，并且容易造成管理混乱，沟通和协作效率低。
2. 对软件质量非常关键的全局性设计决定被拖延到分头开发期间草率决定，严重降低了软件产品的质量。
3. 没有完成化解重大技术风险的职责，可能造成整个项目的失败。
4. 团队成员对架构师意见很大，团队士气低落。
常见的高来高去的架构
1. 缺失主要架构视图。
越是复杂的系统，越是应该从多个方面进行架构设计。如果遗漏了对团队某些角色的指导，那么会对开发进度和开发质量造成眼中影响。如果存在这种现象，应该对遗漏的架构视图进行设计。
2. 浅尝辄止，不够深入。
对架构设计不够深入，依然停留在概念阶段。概念架构虽然‘有用’，但很多时候不是‘够用’，很容易将重大技术风险遗留到后续开发中。如果存在这种现象，应该将设计决策必须细化到和技术相关的层面。
3. 名不副实的分层架构。
指那些号称采取分层架构，却仅用分层来尽心职责划分，而没有规划层次之间的交互接口和交互机制。如果存在这种现象，应该步步深入，明确各层之间的交互接口和交互机制。
参考文献《软件架构设计》 温昱