爱华网服务是在整个模型中作为独立接口的操作，定义Service的时候需要使用模型语言，同时Service本身无状态。如果说Entity强调的是行为，那么Service则强调的是操作，而且这个操作强调的是和一个或多个对象的关系，因此Service往往会以动宾方式进行命名。
资金转账功能即属于一种领域层的Service，其原因是这个功能不是账户对象某一个对象实例的行为，而是多个对象实例的行为。获取用户信用等级也可能是领域层的Service，因为不仅仅是涉及到一个对象，而且是涉及到多个对象协同才能给完成，而不是属于单一对象的职责。
结合系统内的SOA化，基于上面的原则对于服务的理解做一些扩展。对于领域层提供出来的服务本身应该整个领域层核心能力的接口暴露，只是暴露方式是通过服务的方式暴露出来。这些服务我们建议是业务服务而不是简单的数据传递，服务本身有明确的业务规则和业务含义，这样更加能够体现领域的核心作用，封装各种业务逻辑而不是简单的DTO或数据CRUD操作而已。
基于上面思考，我们期望不仅仅是将不属于单个对象职责的内容放到Service中，也希望将单个对象需要暴露的核心业务能力或接口放到Service中。对于应用层和领域层的关系而言，应用层调用服务接口，而逻辑层则是具体的服务实现。逻辑层和领域层只能通过Service进行交互。对于Factory封装复杂对象的创建和管理，Repository负责数据的持久化，Factory本身并不体现业务能力，所有的业务能力全部体现在Service中来实现。
再转移到应用层，结合SOA参考服务架构，对于应用层可能还有Service，这里的Service应该理解为一种组合服务，跨多个Service的一种能力组合。这种组合服务本身还可以聚合为Service，实现一种复用。或者就是应用层直接通过代码来实现多个服务的装配，服务流转。注意在这种模式先应用层重点是服务的流转，服务的协同，服务的组合，而不是具体业务规则的实现。业务规则和能力完全在领域层内聚。
