脚踏实地系列之领域驱动设计--Command是个设计模式

     可能有细心的人，会发现我们在上图有一个实体对象是Command。而且貌似通过这个Command 和很多对象都有相应的关联关系，这个Command到底是什么东西？

      首先，Command是个设计模式。再者说明一下，我们在前面有一个Excel表格中也出现了命令这个列，这个列对应下的一些词和Command并没有必然的联系。

     我们都知道，对于一个实体对象的维护，一般都有新增，查询，修改，删除这样几个常见的操作（技术层面的），但是注意我们在业务层面很少用这样的语言。比如一个订单实体，在创建订单以后，后续可能面临多种操作：发货，收获，退款等等，这个在技术层面就是更新，但我们在这里不能用单纯的update 来代替，而应该用更加贴近业务场景的描述发货，收获，退款等等这样的字眼，而这些字眼背后代表的就是针对实体对象进行相应的操作，那么我们一旦把这个操作抽象化出来，那么就是一个Command，而且这个Command对象还是一个领域对象。

       但是不是每个操作我都会用到Command，比如查看这个操作，我更多的是用到服务的调用，因为查看对于这个领域的实体对象不产生任何的附加作用（即可以认为具备幂等性的）。

       这样当我们设计好这样的Command时，我们就可以将其持久化到数据库中（因为Command本身也是实体）；第二在代码实践过程中，我们可以根据流程规则的差异性，我们可以设计不同的Command流程模版， 统一交付给Command执行引擎来统一执行。当然我们也要注意，不是任何操作都需要Command化，上面提到的查看类操作，还有创建类操作，我还是建议直接用服务的方式来进行。

    当我们把Command 也作为一种实体对象来考虑时，你会发现，在整个领域内的对象设计时，不会设计和产生太多的实体对象，更多的是值对象。而且后面需求有变化，比如需要增加实体对象一些辅助性的功能操作时，仅仅通过增加Command 模版就可以快速的完成，而不影响其他的代码。符合面向对象的几大原则。

   最重要的一个原因是：当我们系统如果需要回溯时，我们可以通过Command对象去回溯整个实体的变化情况，这样对生产问题的排查和解决带来了极大的提高，而且对系统架构产生了更多扩展的可能性。

    所以请记住：Command是个设计模式，而且这个模式非常的有用！