应用服务介绍

对于一个新的设计元素，可以先假定不需要它，等到确实认识到它的作用再引入。那么，应用服务为我们带来了哪些好处呢？

• 应用服务帮助简化表现层操作
  　　以MVC为例，如果没有应用服务，那么控制器将直接调用仓储，设置查询条件，转换DTO等。
  　　当控制器操作变得复杂，你会想办法把控制器代码分离出去。分离控制器代码的最好方法就是建立对应的应用服务，不要轻易的分离控制器本身，因为这会导致查找视图变得困难，并且破坏了约定，导致更高的维护成本。
• 应用服务为表现层提供唯一的API访问点
  　　当一个控制器操作变得复杂时，编写控制器的程序员需要了解更多的知识，这些操作是由哪些聚合、领域服务、基础设施服务等构造元素组装起来的呢，调用顺序如何？
  　　这是表现层应该关心的问题吗？
  　　表现层应该只关心界面展示，这是表现层的基本职责所在，其它职责尽量转移到后方。
  　　应用服务将细粒度操作打包为粗粒度操作，让编写表现层的程序员不再东张西望，他只需要记得一件事：需要访问任何后端的操作，找应用服务就对了。
• 应用服务为多个表现层减少冗余代码
  　　如果需要多个表现层，比如需要开发一个WPF程序，功能与MVC完全一样，这时候，你会发现表现层充斥大量重复代码。
  　　引入应用服务后，表现层代码更简洁，冗余代码更少，创建多个表现层更加轻松。
• 应用服务集成和装配领域层与基础设施层
  　　为了保持领域层的纯净，我们采用依赖倒置原则，领域层只拥有操作接口，具体实现却在基础设施层，最终要能运行起来，必须将它们组装到一起。
  　　如果没有应用服务，控制器将需要自己进行装配，这增加了表现层的负担，应用服务承接了这项工作，让表现层专心干自己的本职工作。
• 应用服务配合DTO优化远程调用性能
  　　当采用了分布式架构，为了提升性能，需要尽量减少远程调用次数。
  　　应用服务在分布式环境充当了远程外观，配合DTO一起解决这个问题。

应用服务与BLL的比较

对于长时间采用传统三层架构的朋友，对于应用服务这个构造是无比的亲切，初步用起来以后，你发现这个应用服务就是BLL的翻版。
　　BLL是传统三层架构的业务逻辑层，很多人直接用BLL来命名业务逻辑层的服务类，我暂时就用这个称呼。
　　BLL是业务逻辑放置的场所，BLL将结果保存到Model实体类中，然后将实体类传递给其它层。
　　应用服务用于协调领域层与基础设施层的操作，应用服务本身不应该完成复杂的业务逻辑。
　　应用服务与BLL的关键区别在于，BLL直接完成业务逻辑，而应用服务会将业务逻辑委托给领域实体或领域服务。
　　从代码上看，BLL主要通过操作Model的属性进行业务逻辑的处理，而应用服务通过调用领域实体或领域服务的方法完成所有业务操作。

领域服务介绍

从前面的介绍，你应该已经发现应用服务是有用的，下面再来看看领域服务。
　　在最理想的情况下，所有的业务逻辑都应该高度内聚到聚合中。但对于更复杂的业务，一般都有比较复杂的流程，这些流程上的控制，放入聚合并不合适，因为这些行为不属于某个聚合。
　　如果把这些行为放到应用服务中，可能导致应用服务非常复杂，业务逻辑也从领域层脱离出来，使业务逻辑的管理更加困难。
　　为了把业务逻辑重新移回领域层，需要添加一个领域服务。
　　现在我们有了应用服务和领域服务两个构造元素，那么，对于一个复杂操作，应该将哪一部分放入应用服务，哪些又放到领域服务呢？
　　书上介绍，业务逻辑可分为领域逻辑和应用逻辑，领域逻辑应该完全放到领域层，不能泄露到其它层去，而应用逻辑应该放到应用层服务。
　　可以看出，说得相当抽象，哪种东西算得上领域逻辑，哪种又是应用逻辑？这个很难精确划分。
　　一个经典的应用逻辑例子是事务控制，事务控制不是客户的需求，但却非常重要，所以把这种东西放到应用层，而不是领域层。
　　那么发邮件的操作是领域逻辑，还是应用逻辑？？有人说是领域逻辑，有人说是应用逻辑，还有人说要看情况。可谓众说纷纭，让你摸不着头脑。
　　不过我们学习的目的不是进行学术辩论，而是切实的提升项目可维护性，所以不用太理会那些考智商的概念，下面谈谈我的用法。
　　对于应用服务，我总是需要它，因为它可以简化表现层开发。
　　对于某些比较简单的业务逻辑，如果发现建立领域服务并未产生太大价值，我就直接放入应用服务中。比如判断一个实体的名称不能重复，这是一个业务需求，首先考虑这个业务逻辑可以放入实体中吗？不能，因为实体本身无法了解自己的名称有无重复。其次考虑需要建立领域服务吗？对于这种简单业务逻辑，创建一个领域服务有点大炮打蚊子的感觉。我会直接将重名检测放入应用服务中，虽然导致有一点业务逻辑散落到应用层，但我未发现对可维护性造成影响。
　　如果业务逻辑比较复杂，我一般会采用TDD方式推进业务开发，这种情况下，建立领域服务是一个极好的选择，因为领域层依赖低，单元测试更方便。
　　不论应用服务，还是领域服务，开发的基本原则是，尽量将业务逻辑委托给领域实体，服务仅做调度的工作。
　　基础设施服务比较好理解，就是提供一些基础支持服务，比如发送邮件等操作。

需要为服务抽取接口吗

学习设计模式时，要求我们面向接口编程，但一些对象大师建议不要过度设计，以免导致不必要的复杂性，在《实现领域驱动设计》一书中提出，应用服务使用独立接口没有什么好处。
　　虽然接口有不少作用，但一般来讲，驱动创建接口的真正需求来自多态。在一般的项目开发中，特别是前期，服务很少具有多态需求，那我们还要不要为服务建立接口?
　　在没有使用Resharper的年代，我使用接口非常小心谨慎，因为从接口定位实现类非常困难，但自从用上了Resharper，接口不再成为障碍。
　　另一方面，IOC框架的使用，让接口的使用进一步普及，我只需要将实现类绑定到接口，在程序中就可以自由使用了。虽然IOC可以直接绑定实现类，但总感觉有点奇怪。
　　最后，对于跨层访问，采用接口互联也符合分层设计原则。
　　对于采用了Ioc框架，并安装了Resharper这样强大的工具，接口不会给你造成任何不便，至于是否导致复杂性，则需要自己体会。
　　代码中采用接口编程，可能在大多情况下都未产生实质的好处，但在需求发生变化时，只需修改Ioc配置替换相关实现，这个扩展性在不花成本的情况下还是划得来的。

服务命名约定

当同时需要应用服务和领域服务，会发现服务取名也很困难。比如用户管理，应用服务叫UserService，如果需要领域服务，也叫UserService就发生冲突 ，但命名为其它可能又不合适。
　　我的办法是应用服务统一以Service结尾，领域服务统一以Manager结尾，这样就可以简单的解决这个问题。对于和我一样的英文菜鸟，可能特别有用。

领域服务（Domain Service）总结

• 对应领域中的一个有意义的跨多个领域对象的操作或动作，如资金转账
• 以动词开头来命名，如TransferService
• 协调多个领域对象完成一个操作
• 无业务状态
• 封装业务逻辑，避免领域逻辑泄露到应用层
• DDD中的三种服务：应用层服务、领域服务、基础服务

区分三种服务的例子

比如应用层有一个资金转帐的服务，该应用层服务主要做以下事情：

• 获取输入（如一个XML请求）
• 发送消息给领域层服务，要求其实现转帐的业务逻辑
• 领域层服务处理成功，则调用基础层服务发送Email通知

领域层的服务做以下事情：

• 获取源帐号和目标帐号，分别通知源帐号和目标帐号进行扣除金额和增加金额的操作
• 提供返回结果给应用层

基础层服务做以下事情：

• 按照应用层的请求，发送Email通知

示例

IRoleAppService.cs

using Rdf.Application.Act.Dtos;
using Rdf.Application.Services.Dto;
using System.Threading.Tasks;

namespace Rdf.Application.Act
{
    public interface IRoleAppService
    {
        Task<JsonMessage> Create(CreateRoleInput model);
        Task<JsonMessage> Update(UpdateRoleInput model);
        Task<JsonMessage> Delete(DeleteRoleInput model);
        Task<JsonMessage> GetInfo(GetRoleInfoInput model);
        JsonMessage GetAll(GetAllRoleInput model);
        JsonMessage BatchDelete(BatchDeleteInput model);
        JsonMessage GetPage(PageInput model);
    }
}

RoleAppService.cs

using AutoMapper;
using Rdf.Application.Act.Dtos;
using Rdf.Application.Services.Dto;
using Rdf.Domain.Entities.Act;
using Rdf.Domain.Repositories;
using Rdf.Domain.Uow;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;

namespace Rdf.Application.Act
{
    public class RoleAppService : IRoleAppService
    {
        private readonly IUnitOfWork _uow;

        private readonly IRepositoryBase<Role> _roleRepository;

        public RoleAppService(IUnitOfWork uow, IRepositoryBase<Role> roleRepository)
        {
            this._roleRepository = roleRepository;
            this._uow = uow;
        }

        public async Task<JsonMessage> Create(CreateRoleInput model)
        {

            var entity = Mapper.Map<CreateRoleInput, Role>(model);
            entity.Id = Guid.NewGuid();

            await _roleRepository.InsertAsync(entity);
            await _uow.SaveChangesAsync();

            return GetErrorMsgByErrCode(0);
        }

        public async Task<JsonMessage> Update(UpdateRoleInput model)
        {
            var entity = Mapper.Map<UpdateRoleInput, Role>(model);

            await _roleRepository.UpdateAsync(entity);
            await _uow.SaveChangesAsync();

            return GetErrorMsgByErrCode(0);
        }

        public async Task<JsonMessage> Delete(DeleteRoleInput model)
        {
            await _roleRepository.DeleteAsync(b => b.Id == model.Id);
            _uow.SaveChanges();

            return GetErrorMsgByErrCode(0);
        }

        public async Task<JsonMessage> GetInfo(GetRoleInfoInput model)
        {
            var entity = await _roleRepository.SingleAsync(b => b.Id == model.Id);

            JsonMessage jsonMsg = GetErrorMsgByErrCode(0);
            jsonMsg.Result = Mapper.Map<Role, RoleDto>(entity);
            return jsonMsg;
        }

        public JsonMessage GetAll(GetAllRoleInput model)
        {
            var entity = _roleRepository.GetAll().OrderBy(item => item.DisOrder).ToList();

            JsonMessage jsonMsg = GetErrorMsgByErrCode(0);
            jsonMsg.Result = Mapper.Map<List<RoleDto>>(entity);
            return jsonMsg;
        }

        public JsonMessage BatchDelete(BatchDeleteInput model)
        {
            return null;
        }

        public JsonMessage GetPage(PageInput model)
        {
            if (string.IsNullOrEmpty(model.OrderBy))
                model.OrderBy = "DisOrder";

            object entity;
            int total = 0;

            if (!string.IsNullOrEmpty(model.Keyword))
            {
                entity = _roleRepository.Get(p => p.Name.Contains(model.Keyword), model.OrderBy, model.PageIndex, model.PageSize);
                total = _roleRepository.Count(p => p.Name.Contains(model.Keyword));
            }
            else
            {
                entity = _roleRepository.Get(model.OrderBy, model.PageIndex, model.PageSize);
                total = _roleRepository.Count();
            }

            JsonMessage jsonMsg = GetErrorMsgByErrCode(0);
            jsonMsg.Result = new PageOutput() { Total = total, Records = Mapper.Map<List<RoleDto>>(entity) };
            return jsonMsg;

        }

        private static List<JsonMessage> ErrMsgList = new List<JsonMessage>()
        {
            new JsonMessage() { ErrCode = 0, ErrMsg = "请求成功"}
        };

        public JsonMessage GetErrorMsgByErrCode(int errCode)
        {
            var model = ErrMsgList.FirstOrDefault(p => p.ErrCode == errCode);
            return new JsonMessage()
            {
                ErrCode = model.ErrCode,
                ErrMsg = model.ErrMsg
            };
        }

    }
}