1. 背景
在架构设计与实现过程中，需要对软件系统做全局的分析与考虑以求全局的认知。在分析和考虑过程中软件的不同层次都有独特的问题。为了在设计阶段做出更全面的决策，以解决绝大部分实现过程中可能遇到的问题，需要对软件开发过程中不同的层次的工作内容进行具体的分析。
所以需要对软件设计与决策提供全局框架，并把握每个层次的关键点。
2. 层次
可以将软件的实现过程分为如图的几个层次，软件从业人员也可以根据图中的层次进行划分。对于软件实现层级的划分也印证了现在的软件设计与实现已经超越了算法和数据解构，对系统结构的设计与治理成为架构设计的重点。分层结构如上图所示，软件分为7个层次：
2.1 代码=数据结构+算法：
在学校学软件的时候有一种普遍的认知：软件=算法+数据结构。在当时（零几年）没有微服务、没有DevOps、没有超大互联网企业，那会对于软件的认识可能就是单体，mfc这种模式的软件。所以，将软件认为就是数据结构加算法即可解决绝大部分问题。
其实这样的认知也是受到时代的局限。在大部分软件都是小型的C/S、B/S的时候，当时最大的问题还是怎样开发一套业务系统的年代，不会涉及到分布式系统的情况下能做出来就很不错了。更不用谈对于软件的认知。
2.2 程序=代码+设计模式：
在代码使用设计模式。为什么？
软件规模在不断的扩大，不断的发展。而在这个过程中遇到的规模化代码的管理问题，可扩展问题，可修改性问题。急需为软件的持续发展提供一种解决方式，让软件规模增长提供管理的方法。
这时小规模的问题通用解决方案可以使用设计模式进行管理。因为每一个设计模式都是解决代码规模化的一部分问题。
2.3 模块=程序+分包模式：
这是伏羲一画开天式的创举，但很少有人提到分包模式。因为现在的mvc，mvp，acp等已经很流行而且已经深入人心。所以分包模式对于现在的开发已经很平常。但是分包模式是第一次进行了高内聚低耦合的实践。
2.4 软件=模块+架构模式：
设计模式之上的架构模式。为什么？
到现在为止并没有对软件系统中的工作内容进行划分，例如：MVC的各种变种。软件层之下的主要是管理代码，代码编写的内容。而架构模式管理的是对于复杂业务下模块的拆分，模块的关系，代码的复用的工作。这部分内容之所以需要做是因为意识到软件的工作中并不是所有的工作都需要用到算法和数据结构，需要将不同的业务之间隔离并确定业务之间的关系。
所以架构模式负责的是给业务分包、模块。让软件中的每一个模块都可以做到单一职责。
2.5 系统=软件+架构风格：
架构模式之上的架构风格。为什么？
上一个层次中已经说明通过使用分包、模块化的方法进行模块的职责的划分。那么一个系统应该以怎样的方式将系统中的服务链接起来。
在常见的架构的定义中有一种：一个程序或计算机系统的软件体系结构包括一个或一组软件构件、软件构件的外部的可见特性及其相互关系。
2.6 平台=系统+企业架构：
架构风格之上的企业架构。为什么？
软件的最终目标是什么？按照作者理解应该是解决人们现实中的切实问题，不管是提升效率、降低成本、提升便利性还是提供特定帮助都是可以通过计算机的计算能力来解决的事情。抱着这个目标去实现
传说中的EA，它最主要的解决问题是：为了_解决_IT与业务对齐、业务和战略对齐_问题。_
2.7 企业架构
企业架构有多种方法论，也有不同层面的解决方案。例如：EA可以有togaf，zachman，dodaf等。产品开发方法有ipd，精益等方法。
我个人一般喜欢以：理想、目标、原则、方法这几个方向去分析一个公司是否真正的解决了现实问题。并根据四个元素去确认公司的目标与个人目标的一致性。
3. 总结
每个层次的认知都是对的，并没有错误一说。这里最主要的区别是你处在什么阶段就会认知到什么样的软件。行业所处的阶段也会影响从业者对于这个行业的认知，就像文中所说的一样认知是受到时代的局限。
就像《演进式架构》中所说的：适度的重复是有益的。而不像之前人们认为DRY，不能重复任何东西。所以，站在邓宁克鲁格的开悟之坡的人并不会去嘲笑处在愚昧之峰的人。
再比如《软件架构：架构模式、特征及实践指南》中所说的：适合的才是最好的。很多时候没有对错，只有合适，在马丁富勒的《单体优先》中也有类似的描述。
在这里说这么多要证明的是：认知处在任何阶段都是正常的，不过需要不断的提升认知。
