在领域模型模式中，我们大都是将服务层看作是业务层的一部分。虽然这个做法非常常见，不过显然，我们还有其他选择。通常来说，服务层为表现层定义了一个接口，从而允许表现层触发一些预定义的系统操作。正如名称表现出来那样，服务层可以看作是表现层结束、业务逻辑层开始的一个边界，服务层用来尽可能的降低表现层和业务逻辑层之间的耦合，让表现层无需关注业务逻辑层中的具体实现组织方式。因此，无论你选择任何一种业务逻辑模式（表模块、活动记录还是领域模型），系统都可以提供一个服务。
实际上服务层不执行任何具体的工作，其功能在于组织各个业务对象，服务层非常了解业务逻辑（包括工作流、组件和服务），进而也非常了解领域模型。服务层不仅组织业务组件，还组织应用程序专有的服务、工作流以及其他任何出现在业务逻辑层中的特殊组件。
用“服务”作为表现层和业务层之间的层的名字是有争议的。这一层可以通过Web服务或WCF服务实现，也可以选择其他的任何一种技术。虽然服务层有“服务”一词，但是我们要将它理解成一个与技术无关的词汇。
服务层位于系统中两个互相通信的逻辑层之间，使两个层能够在松散耦合并优美彼此离开的同时，仍旧可以完美地彼此通信。
每个用户驱动的交互的核心都包括两个参与者：表现层的用户界面和服务层实现的用来响应用户操作的模块，这就是说服务层不仅用来组织业务逻辑，也许要与持久化层进行交互。所有的交互都源于表现层，并从服务层获取响应，根据接收到的输入，服务层将组织业务逻辑层中的组件 - 包括服务、工作流和领域模型中的对象，并根据需要调用的数据访问层。
不仅仅只有服务层会发送数据库操作请求，也许还有其他情况，业务逻辑层也可能包含一些工作流、或业务服务需要使用到的数据访问层。业务逻辑层唯一需要完全和数据库细节分离的部分就是领域模型。
面向服务
通常来说，服务层就是一系列暴露了逻辑上相关方法的类，供其他层（通常是表现层）调用。在这种抽象层面上，服务层和事务脚本库非常类似。离开了技术上下文，“服务”一词就简单的表示能够为某一层提供服务，并把请求发送给另一层的软件组件，而“服务层”则表示位于两个需要通信的层之间的、一系列服务的集合。直接了当的说，目前越来越多的人认为“服务”并不仅仅是一些能够处理请求的代码，出现这种状况的一个主要原因是面向服务和面向服务架构SOA的日益流行。
面向服务是一种设计业务的方式，由一系列互相连接的服务组成，面向服务并不是某种特定的技术，而更像是一种不同的组织业务操作的方式。在SOA的世界中，应用程序是由一系列独立的服务经过组合和集成得到的，这个集成的过程可能类似于以前流行的快速应用程序开发中的窗体设计过程。不过在SOA应用程序中，最小的构建块是服务，而不是组件。
服务可以充分使用其所处的环境，且其生命周期控制也更加自主。服务层中的服务要比简单的类更加适合，甚至可以说，若不是为了实现服务，甚至没有必要独立成专门的服务层。
服务可以自治、可发现资源、和固定接口。除此之外，服务通常被设计成一个无状态的组件。一般来说，无状态的组件可伸缩性比较好，其整体实现也相对简单，且能应用在更多的不同场景中。
服务层中的服务
从架构上讲，服务层应用了软件设计中一个通用且人人皆知的原则低耦合。可能还应用了另一个原则高内聚。这是一个通过中间层解除用户界面和中间层的耦合来实现的。
面向服务的出现让架构师更兴致勃勃的将一些面向对象服务特性应用到服务层中，结果就是所有的服务层都是由且仅由一些服务组成。服务层作为模式存在的根本原因就在于，服务和面向对象的概念已逐步应用到内部应用逻辑以及外部客户操作之上。
服务层可以作为一个远端的层，不过根据实际情况取决于项目的客户端。服务层也可能是表现层中的一部分。如果那样，服务层不需要设计成Web服务，而是可以用支持服务的组件或一些普通的类来实现，这里的重点是服务层所提供的抽象，而不是其具体的实现方式。支持服务的组件是指.Net Framework类支持COM+服务的机制，当你需要使用一些COM+提供的额外服务，例如，实时激活、对象池、声明式安全或分布式事务等。例如WCF是需要远程调用时，作为服务层创建服务的良好选择。WCF作为一种服务技术来说，其最大的优势就是其配置能力能够方便的向解决方案中添加一些面向方面的特性。
服务层作为用户界面和中间层提供了一个统一的契约，因此中间层即可专注于实现应用逻辑。应用逻辑属于业务逻辑的一部分，其设计直接源于需求中的用例。若没有了服务层，则需要从表现层直接调用到应用程序服务中，这就会造成一个太过细粒度的远程接口，从而导致过多的交互。
服务层是由一系列粗力度的服务组成的，这也叫做宏服务。宏服务是按照用例来组织操作的，其中并不包含任何核心业务相关的领域逻辑。表现层和服务层都不（或者不应该）包含业务逻辑，表现层仅仅了解服务层提供的粗粒度接口，服务层仅仅了解一系列可用的交互方式，并关注一些具体细节，包括必要的事务、资源管理、协调、数据转换。
服务层实战
何时使用：服务层应该用在有一定复杂性的应用程序中，只是随随便便、简简单单使用几周的Web站点，服务层也不能带来一些开销和好处。SOA和web服务确实存在关系，SOA不是Web服务，不过某个Web服务可能是SOA架构的产物。SOA是设计哲学，而不是编写服务的具体技术。
位置在哪里：服务层的位置是在本地还是远程调用取决于当前情况。若服务层可以容易地在各个物理层中移动，那将是个最好的结果。这样看来，类似WCF的服务技术是一个最好的选择。在将服务层中的某个类升级成服务并不是个大动作，这个操作通过重构解决。
处理角色和安全：若对安全非常在意，那么可以让服务层中的每个方法都检查调用者的标识，并拒绝未认证用户的访问。若不想在每个服务中都重复检查，那么可以采用声明式的方法保证安全，即为服务方法添加安全相关的特性。
面向服务架构
分布式系统中对服务层的关注点和需要是与面向服务紧密相关的。面向服务是一种理念，让你将软件架构的功能看作是一系列业务流程的集合，这些业务流程被封装并暴露成一系列可以交互操作的服务。
SOA的原则是：边界清晰、服务自治、使用契约，而不是类、兼容性基于策略。
边界清晰：SOA服务将显示暴露出清晰的契约，所有与该服务的交互都要通过该公共接口进行。在设计服务时，开发人员应该尽可能让接口简单，同时又不影响日后的增强。
服务自治：自治服务是一个松散耦合的服务，该服务的设计和部署都独立于其他服务，但是可以通过基于契约的消息和策略与其他服务进行通信。服务应该设计成静态的，且在服务发布之后不应该再有修改，若想满足该需求，就必须选择基于消息的语义，因为其灵活性允许你将他作为契约的一部分。
使用契约、而不是类：无论选择各种技术，都是通过基于常用、规定的数据格式来传递数据的。定义服务就是定义服务契约以及一系列数据契约。
兼容性基于策略：服务可达并可调用并不能成为使用者调用该服务的原因，关键之处在于使用者必须能够判断某个服务是否满足了它的需求。服务和数据契约指的是结构的兼容性，也就是某个指定的服务是否能完全满足使用者的期待，语义兼容性也应该通过一个公开可访问的、标准的策略暴露出来，供外界查看。
很多SOA模式在服务层适用，但是反模式也值得介绍。SOA反模式常见的两种是：CRUDy和Chatty聊天式模式，这两个模式都是有关服务契约的。CRUDy接口只是一个漂亮的名字而已，真正的敌人是糟糕的设计。与CRUDy相关的是聊天式模式，该反模式描述的是某个服务契约以类似PRC的方式交流行为。换句话说，这种服务暴露了表现层一系列细粒度的方法，表现层要一个接一个的调用才能完成需要的操作。
小结
服务层一般总是有必要提供的，因为它能够解除应用程序接口和中间层之间的耦合。唯一不会考虑使用服务层的情况是，你非常确定程序有且仅有一个表现层。
相关博客：
- .Net企业级应用架构设计之当代的架构师和架构
- .Net企业级应用架构设计之UML
- .Net企业级应用架构设计之设计原则和模式
- .Net企业级应用架构设计之业务层设计
- .Net企业级应用架构设计之服务层设计
- .Net企业级应用架构设计之数据访问层
- .Net企业级应用架构设计之表现层设计