在设计中，业务层常常可以进一步细分为：业务逻辑单元和应用逻辑单元，其中业务逻辑单元包含各种处理逻辑和验证规则；应用逻辑单元则是由服务类组成的“薄层”，负责提供粗粒度的接口方法，以供外界使用。

显示层可以通过调用应用层进行逻辑操作，而且显示层还可以直接绕过应用逻辑层，从而调用业务类进行相关的逻辑处理。

在设计中，有时候为了增加灵活性和扩展性，我们希望显示层不依赖业务类，这样就可以让业务类的结构变化不影响显示层为了达到这个目的，数据的交换则需要用数据传输对象（DTO）来辅助完成。

数据传输对象就是数据的载体，负责在显示层和应用逻辑单元之间传输数据。

在采用了DTO之后，应用逻辑单元就需要处理DTO和业务之间的数据转换了：

（1）一方面，应用逻辑单元将业务层的数据装载到DTO中，然后将DTO传递给显示层。

（2）另一方便，应用逻辑单元将显示层传递的DOT进行转换，传递给业务层，因为DTO也逻辑是没有任何关系的，如果此时再把这些转换逻辑放在业务层就不合适了，所以需要将应用逻辑单元从业务层中提出来，让其成为单独的逻辑层，这就形成了“服务层”。那么再修改设计，业务逻辑被分散在了两个层中，这给以后的维护和开发带来了复杂性，所以我们还希望将服务层移回到业务层。那么如何才能做到“鱼和熊掌兼得”呢？

首先要分析服务层：此时的服务层不仅仅包含了业务逻辑和相关流程的处理，也包括了异常、事务的处理、DTO数据转换。

并且此时服务层业务逻辑的完成依然是组合业务和相关的辅助类来进行的。或许我们可以把与业务逻辑再次移回到业务层中，也就是说，在业务中依然放置服务层。而在分离出来的、业务层之外的服务层中则可以添加更多的功能，例如跟踪、缓存等。

接下来要考虑的问题是：在服务层中方法是否有可能被远程调用。如果有可能，那服务层就要运行在相应的运行环境中了，并且还需要进一步地考虑远程调用者有关性能的问题。

到这里，服务层出现的原因就应该清楚了：简化外部操作同时达到解析的目的。服务层定义了应用的边界和客户多能看可操作集，它封装了应用的业务逻辑、事物控制及操作的协调能力。简单的理解就是：服务层起到隔离和提供相关业务逻辑、事务控制及操作操作的协调能力。简单的理解就是：服务层起到隔离和提供相关业务逻辑操作的作用，并且还包含了相关控制逻辑。