主要的三层

层	职责
表现	提供服务，信息显示（例如，在窗体或HTML中，处理用户请求（鼠标点击，键盘敲击），HTTP请示，命令行，批处理API）
业务	系统实际关注的逻辑
数据源	与数据库通信，消息系统，事务管理，其它功能

表现逻辑处理用户和软件间的交互。这可能就像一个命令行或基于文字的菜单系统。但现在，它更可能是一个富客户端图形界面或一个基于HTML的浏览器UI。（在这本书中，我使用富客户端（rich client）表示一个与HTML浏览器相对的Windows/Swing/fat-client UI。）表现的主要职责是显示用户信息，和将来自用户的命令解释为业务和数据源。

数据源逻辑处理与代表应用程序完成任务的其它系统间的通信。它们可能是事务监控器，其它应用，消息系统等。对于多数企业应用程序，数据源的最大部分是数据库，它的最大职责是存储持久数据。

最后一部分是域逻辑（domain logic）也称作业务逻辑（business logic）。它处理你的应用程序的问题域。包括基于输入和存储数据的计算，验证来自表现层的任何数据，根据来自表现层的命令指出分派的数据源逻辑。

有时，层以以下方式进行组织：业务逻辑层对表现层完全隐藏数据层。然而，更多情况下，表现层直接访问数据存储。虽然这并不完美，但在实践中这方式工作得更好。表现层可以解释来自用户的命令，使用数据源取出相关数据，然后，让业务逻辑在显示前处理这些数据。

一个应用程序通常拥有这三个主题区域的多个包。我们设计的一个不仅被终端用户通过富客户端界面操作，也可以通过一个命令行的应用程序会拥有两个显示层：一个用于富客户端界面，一个用于命令行。存在多个数据源组件的原因可能是因为多个不同的数据库，但是更可能是为了因为已存在的多个包之间的通信。即使是业务层分隔成清晰地彼此独立的区域。特定的数据源包可以只在特定的业务层包中使用。

我来谈一下用户。很自然地会提出当一个不是由人驱动软件时会发生什么的问题。这可能是某些新的或流行的事物，例如，Web服务或某些平凡但有用的方式，如批处理方式。在后一种情况下，用户是客户端程序。在这一点上在显示层和数据层显出很多的相似点，因为它们都是关于与外界世界的联系的。这就是隐藏在Alistair Cockburn的门边形架构模式背后的逻辑，它将任何系统形象化为一个被通向外部系统的接口包围的核心。在六边形架构中外部的任何东西都是一个外部接口，因此它是一个对称的视图，而不是我的不对称的层次方案。

但是，我发现这种不对称是很有用的。因为，你提供给其他人服务，同时也使用其他人提供的服务，在这两种接口间我认为可以划分出一个明显的差别。考虑核心，在表现和数据源间我认为有实实在在的不同。表现是你的系统提供给其他人的服务的接口，不管这个“其他人”是复杂的，如人类，还是简单的，如过程程序。数据源是提供给你的服务的接口。我认为把这些认为是不同的是有好处的，因为客户的不同会改变你思考服务的方式。

虽然你可以识别出每一个企业应用程序的共同的三层：表现、业务和数据源，但是，如何划分它们决定于应用程序的复杂程度。一个从数据库中取出数据，显示在Web页面上的简单脚本可能只是一个函数过程。在这种情况下，我仍然努力分出三层，但是我只是通过将每层的功能封装单独的子程序中。当系统变得更加复杂时，我就会将三层分散单独的类中。当复杂性继续增加时，我会将这些类分散到单独的包中。我一般的建议是针对你的问题选择最合适的分离方式，但是，至少确保在子程序级别做某种方式的分离。

对于分享，有一个关于依赖的固定原则：业务和数据源绝对不能依赖于表现。即，业务或数据源中子程序不能调用表现层中的代码。这个原则使得在同一基础上更换不同的表现变得更容易，并且，使得修改表现而不用过多的关心下层变得更容易。

处理业务逻辑的最难的一部分工作似乎人们经常发现辨别出什么是业务逻辑，什么是其它形式的逻辑是很困难的。对于这个问题，我喜欢的一个不正式的测试是想象给应用程序加入一个根本不同的层，例如，向一个Web应用程序加入命令行接口。如果在做这个工作的时候，你必须重复任何功能，这就是业务逻辑已经泄露到表现的迹象。相似地，如果用XML替代关系数据库，你是否需要重复某些逻辑？

对此一个很好的例子是，一个系统包含一个产品列表，在此列表中，所有的比上月多售出10%的产品被标记为红色。为了实现这个功能，开发者在表现层放入逻辑：比较本月与上月的销售，如果相关超过10%，就标记为红色。

问题是这将业务逻辑放入了表现中。为了分离层，你需要在业务逻辑层中一个方法以显示一个产品是否提高了销售量。这个方法比较两个月的销售量，返回一个布尔值。表现层仅仅调用这个布尔方法，如果返回true，标记产品为红色。这种方式将处理过程分离成了两部分：决定是否加亮和选择加亮的方法。