一个简单的例子如下：

customer是该聚合的根，其他的都是内部对象，如果外部需要用户地址，拷贝一份传递出去即可。显而易见，用户如果不存在，其他信息均无意义。

工厂(Factories)

在大型系统中，实体和聚合通常是很复杂的，这就导致了很难去通过构造器来创建对象。工厂就决解了这个问题，它把创建对象的细节封装起来，巧妙的实现了依赖反转。当然对聚合也适用（当建立了聚合根时，其他对象可以自动创建）。工厂最早被大家熟知可能还是在设计模式中，的确，在这里提到的工厂也是这个概念。

但是不要盲目的去应用工厂，以下场景不需要工厂：

a)构造器很简单

b)构造对象时不依赖于其他对象的创建

c)用策略模式就可以解决

仓库(Repository)

仓库封装了获取对象的逻辑，领域对象无须和底层数据库交互，它只需要从仓库中获取对象即可。仓库可以存储对象的引用，当一个对象被创建后，它可能会被存储到仓库中，那么下次就可以从仓库取。如果用户请求的数据没在仓库中，则会从数据库里取，这就减少了底层交互的次数。当然，仓库获取对象也是有策略的，如下：

PS:仓库看起来有些像Infrastructure Layer的东西，但其实不然，仓库更像是本地缓存，需要时才会访问数据库

结束语

CQRS本身也是一种架构模式，但更多的是它被应用在DDD中。因为DDD中有工厂和仓库来管理领域模型，前者主要用于创建，而后者则用于存储。这就表明在DDD中是默认将读写分离的，DDD似乎就天生和CQRS有着无缝的链接。

CQRS往往要求数据库进行读写分离，具体来说，所有的更新操作均无返回值(void)，而读操作才返回对应的值。在实现CQRS时，又和事件源(Event Source)相结合，以下是一个简单的交互过程：

客户端发起一个请求，服务端将其映射为一个命令，该命令会从仓库中读取一个相关的聚合，对该聚合进行操作，将会生成一个事件源，将该事件发送出去，接收方收到消息后（并不是立刻）将会更新领域对象，完成一次更新操作。

在此基础上，还有称之为六边形的架构风格，它将DDD的领域模型包裹在内，外围含有多种适配器来适配各种通信方式，总体来说，我觉得无论是DDD,CQRS还是六边形，都是一种架构的设计思路，没有绝对的优势，同时也有各自的复杂度，并不容易理解，但有时在软件设计时，不妨多学习一下其中的小细节和思路，必然能够有所收获。

至于能否应用？如何应用？，笔者只能说不能生搬硬套，需要有一定的实践经验才能去尝试，一般情况下，结合项目特点，能适当的灵活采用其中的设计思路即可