分层
在分解复杂的软件系统时，软件设计者用的最多的技术之一就是分层。在计算机本身的架构中，可以看到：到处都有分层的例子：不同的层从包含了操作系统调用的程序设计语言，到设备驱动程序和CPU指令集，再到芯片内部的各种逻辑门。网络互联中，FTP层架构在TCP层之上，TCP架构在IP之上，IP又架构在以太网之上。
当用分层的观点来考虑系统时，可以将各个子系统想象成按照“多层蛋糕”的形式来组织，每一层都依托在其下层之上。在这种组织方式下，上层使用了下层定义的各种服务，而下层对上层一无所知。另外，每一层对自己的上层隐藏其下层的细节。因此，第4层使用第三层的服务，第3层使用第二层的服务，第4层无需知道第二层的细节。（当然，并非所有的分层架构都这么隔绝，但绝大多数是不透明的。）
将系统按层次分解有很多重要的好处
-
在无需过多了解其他层次的基础上，可以将某一层作为一个有机整体来理解。例如，无需知道以太网的工作细节，你照样可以在TCP上构建FTP服务。
-
可以替换某层的具体实现，只要前后提供的服务相同即可。例如，FTP服务无论是在以太网，PPP上，还是网络运营商使用的任何网络上都无需改变，而且与提供传输电缆的网络运营商无关。
-
可以将层次间的依赖性减到最低。假设网络运营商改变了物理传输系统，但只要IP层不变，FTP服务就可以不改变。
-
分层有利于标准化工作。TCP和IP就是关于它们各层次如何工作的标准。
-
一旦构建好了某一层次，就可以用它为很多上层服务提供支持。因此，TCP/IP同时被FTP、telnet、SSH和HTTP使用。否则，所有这些高层协议都必须编写它们各自的底层协议。
分层是一种重要的技术，但也有缺陷： -
层次并不能封装所有东西。有时它会为我们带来级联修改。最经典的例子就是在一个分层设计的企业应用中，如果要增加一个在用户界面上显示的数据域，就必须在数据库中增加相应的字段，还必须在用户界面和数据库之间的每一层做相应的修改。
-
过多的层次会影响性能。在每一层，一般都会从一种表现形式转换到另一种。
企业应用中层次的演化
最早的批处理，单一文件，不需要层次。
20世纪90年代，随着客户端/服务器系统的出现，分层的概念更加明显了。这样的系统是一个两个层次的系统：客户端包括用户界面和其他应用代码，服务端通常是关系型数据库。常见的客户端工具如VB、PowerBuilder和Delphi。这些工具使得构建数据密集型应用非常容易。因为它们的用户界面控件通常是sql感知的。因此，可以将控件拖拽到“设计区域”来建立界面，然后再使用属性表单把控件连接到后台数据库。
如果应用仅仅包括关系数据的简单展示和修改，那么这种客户端/服务器的系统的工作方式非常合适。问题来着领域逻辑：如业务规则、验证、计算等。通常，人们会把它们写在客户端，但是这样很笨拙，并且往往直接把领域逻辑直接嵌入到用户界面。随着领域逻辑的不断复杂化，这些代码将越来越难以使用。而且，这样做很容易产生冗余代码，这意味着简单的变化都会导致要在很多界面中寻找相似代码。
另外一种办法是把这些逻辑放到数据库端，作为存储过程。但是，存储过程只提供有限的结构化机制，这将再次导致笨拙的代码。而且，很多人喜欢关系型数据库的原因之一是SQL是一个标准，允许他们更换数据库厂商。由于存储过程都是数据库厂商私有的，因此更换数据库厂商附加代价太大。
在客户/服务器方式逐渐大众化的同时，面向对象方式开始崛起。面向对象为领域逻辑的问题找到了答案：转到三层架构的系统。在这种方式下，在表现层实现用户界面，在领域层实现领域逻辑，在数据库层存储数据。这种方式使你可以将复杂的领域逻辑从代码界面中抽取出来，单独放到中间层，用对象加以建模和组织。