[转] (CQRS)命令和查询责任分离架构模式（二）之 Command的实现

概述

继续引用上篇文章中的图片（来源于Udi Dahan博客），UI中的写入操作都将被封装为一个命令中，发送给Domain Model来处理。

我们遵循Domain Driven Design的设计思想，因此所有的业务逻辑都只在Domain Model中处理，Command中将不会带有业务逻辑。Command中的代码无非是通过Repository获取某些个聚合根(Aggregate Root)，然后将操作委托给相应的领域对象或领域服务来处理，仅此而已。

实现

实现上，我们会涉及三个东西：

(1) Command对象

Command对象的作用是用来封装命令数据，所以这类对象以属性为主，少量简单方法，但注意这些方法中不能包含业务逻辑。

举个用户注册的例子，用户注册是一个命令，所以我们需要一个RegisterCommand类，这个类定义如下：

public class RegisterCommand : ICommand
{
    public string Email { get; set; }

    public string NickName { get; set; }

    public string Password { get; set; }

    public string ConfirmPassword { get; set; }

    public Gender Gender { get; set; }

    public RegisterCommand()
    {
    }
}

这个类的每个属性基本上都对应着注册表单中的一个输入（为了方便起见，上面的每个属性都是public set，但若属性不多不影响编码，最好把属性都改成private set，然后将属性的值通过构造函数传入）。当用户点击“注册”按钮时，Controller（假设使用MVC作为表现层模式）中会创建一个RegisterCommand的实例，设置相应的值，然后调用CommandBus.Send(registerCommand)，然后根据执行的情况显示相应的信息给用户。（CommandBus后面会讲到）

(2) CommandExecutor

CommandExecutor的作用是执行一个命令，对于注册的例子，我们会有一个RegisterCommandExecutor的类，它只有一个Execute方法，接受RegisterCommand参数：

public class RegisterCommandExecutor : ICommandExecutor<RegisterCommand>
{
    private IRepository<User> _repository;

    public RegisterCommandExecutor(IRepository<User> repository)
    {
        _repository = repository;
    }

    public void Execute(RegisterCommand cmd)
    {
        if (String.IsNullOrEmpty(cmd.Email))
            throw new InvalidOperationException("Email is required.");

        if (cmd.Password != cmd.ConfirmPassword)
            throw new InvalidOperationException("Password not match.");

        // other "Command parameter" validations

        var service = new RegistrationService(_repository);
        service.Register(cmd.Email, cmd.NickName, cmd.Password, cmd.Gender);
    }
}

在Execute方法中，我们需要先验证Command的正确性，但需要注意的是，这里的验证只是验证RegisterCommand中的数据是否合法，并非验证业务逻辑。例如，这里会验证邮箱是否为空且格式是否正确，但邮箱格式正确并不意味着就可以注册，因为系统可能要求18岁以上的成年人才能注册，而这属于业务逻辑，RegistrationService将会负责确保所有的业务规则不被破坏，RegistrationService属于Domain Service，存在于Domain Model中。

可以看到，CommandExecutor中主要有两部分工作，一是验证传入的Command对象是否合法，二是调用领域模型完成操作。上一篇文章中提到的Command是一个概念层次的Command，它不单指(1)中的Command，而是包含了(1)和(2)等。

PS: 记得三四年前纠结于“三层架构”的时候，最搞不懂的应该算是“业务逻辑”了，现在似乎有点领悟。“业务逻辑”中关键的词是“业务”，这也是它和其它逻辑如应用逻辑区分开来的关键因素，如果一个逻辑带有“业务价值”，那它就算“业务”逻辑，否则就不算。比如下订单时，如果客户的退款次数超过100，那就不允许下单，这是业务逻辑；而"注册时两次输入的密码必须一致"则不算业务逻辑。但我仍有个问题，要求Email必须唯一算不算业务逻辑呢？我个人倾向于认为它是业务逻辑。那邮箱格式必须正确（即中间必须有@符号等等）算业务逻辑吗？个人倾向于认为是不算，如果不算业务逻辑，领域模型中需要对其进行验证吗？个人倾向于不用在领域模型中验证，这些逻辑应该在CommandExecutor中进行验证。不知道大家的看法如何？

(3) Command Bus

用于执行Command的是CommandExecutor，但CommandExecutor却并不用来在UI层调用，UI层中只会用到Command对象和即将提到的Command Bus。Command Bus的作用是将一个Command派发给相应的CommandExecutor去执行。在开发UI层时，我们不需要关心Command会被哪个Executor执行了，而只要知道，上帝赐予了我们一个CommandBus，我们只要创建好Command对象，扔给它，神奇的CommandBus就会帮我们把它执行完。这样一来，对于UI层的开发来说，所涉及的概念很简单，涉及的类也少，大部分的工作都是得到表单中的输入，封装成Command对象，扔给CommandBus。

下面是注册的例子的Controller：

public class AccountController : Controller 
{
        [HttpPost]
        public ActionResult Register(RegisterCommand command)
        {
            if (ModelState.IsValid)
            {
                try
                {
                    CommandBus.Execute(command);
                    FormsAuthentication.SetAuthCookie(command.Email, false);

                    return RedirectToAction("Index", "Home");
                }
                catch (Exception ex)
                {
                    ModelState.AddModelError("Error", ex);
                }
            }

            return View(command);
        }
}

CommandBus的实现也很简单。首先，我们需要让CommandExecutor都实现一个泛型接口：

public interface ICommandExecutor<TCommand>
    where TCommand : ICommand
{
    void Execute(TCommand cmd);
}

其中ICommand是一个空接口，没有任何方法（即Marker Interface），它的作用是实现编译时约束，这样我们可以限制传入CommandExecutor的都是Command对象，而不是不小心传错的User对象（所有的Command对象都必须实现ICommand接口）。

然后，把CommandBus写成这样：

public static class CommandBus
{
     public static void Send<TCommand>(TCommand cmd) where TCommand : ICommand {
        var type = typeof(TCommand);
        var executorType = FindExecutorType(type);
        var executor = Activator.CreateInstance(executorType);
        executor.Executor(cmd);
    }
}

在这个Send方法中，我们通过反射获取到泛型参数为传入的Command对象的具体类型的Executor类，再调用其Execute方法即可。上面的代码是伪代码，实际实现中我们可以通过IoC框架来简化这个过程，另外也可以做一些改进，例如将CommandBus设计为扩展点之一。另外我们还可以将UnitOfWork（相当于平常的EntityFramework中的IDbContext，Linq 2 SQL中的DataContext）的生命周期在CommandBus中进行控制。

比较完整的CommandBus代码如下（仍有小部分伪代码）：

public interface ICommandBus
{
    void Execute<TCommand>(TCommand cmd) where TCommand : ICommand;
}

public class DefaultCommandBus : ICommandBus
{
    public void Send<TCommand>(TCommand cmd) where TCommand : ICommand
    {
        UnitOfWorkContext.StartUnitOfWork();

        var executor = ObjectContainer.Resolve<ICommandExecutor<TCommand>>();
        executor.Execute(cmd);

        UnitOfWorkContext.Commit();
    }
}

其它的代码不贴在文章中，所有代码可以文末处下载。

这样我们就完成了CQRS中Command的一个基本实现。

一些注意点

(1) Command表示想要执行的命令，所以Command类的类名应当是动词的形式。例如RegisterCommand, ChangePasswordCommand等。不过Command后缀则是可选的，只要能保持一致即可。

(2) Command和CommandExecutor是一一对应的。也就是说，一个Command只会对应一个CommandExecutor，这和后面的事件有区别，事件是一对多的，一个Event可以对应多个EventHandler。

(3) 从文中的AccountController的Register Action中可以看到，Command对象也起到了DTO(Data Transfer Object，在这个例子中感觉称作View Model也无妨)的作用，这也是把Command和Executor相分离，不把Execute方法直接写在Command类中的原因之一。

(4) 注意Command的类名的重要作用，每个Command类的名称都清晰地表达了一个意图，例如ChangePasswordCommand清晰的表达了这个命令是要修改密码，所以千万不要随意"复用"Command，这里的“复用”指的是，看到某两个Command中有完全一样的属性，就觉得没有必要使用两个Command，而把它们合并成一个Command，这样的"复用"会让系统变得越来越难以理解，虽然它可能的确减少了几行代码。

(5) 命令通常是用“发送”来描述，而事件则是用“发布”来描述，所以CommandBus中的方法名称个人认为应该用Send比较合适，而不用Publish之类的。

代码下载

http://files.cnblogs.com/mouhong-lin/CQRS.zip

说明：下载的代码和文章中的代码不完全一致，但也不会有太大差别。示例代码中只实现了Command和用户注册功能，其它的如事件之类皆未包含。

PS: 关于技术文章的写作，我最怕的是自己的理解有偏差，以致于造成不好的影响，但不写又没有讨论。今晚突然想到一个自我感觉比较不错的建议：有兴趣的童鞋在阅读的过程中，若感觉某句或某观点不准确，可以以评论的形式提出，之后作者以不删原句的形式进行修改（将原句子用删除线划掉），这样既可以让文章变得更严谨，同时也会清楚的看到哪些观点经过了什么样的修正。