DDD 中关于应用架构的那些事( 四 ) _架构

在实际开发中，对 Query 的处理其实是比较灵活的，其目的无外乎是提高查询的效率，另一方面也可以保证领域模型职责的单一。通常在查询相对简单的时候会复用领域模型，在稍微复杂时，会直接访问底层的数据模型，如果查询变得更加复杂，会将数据的存储也独立出来。
下面我们就依次说说这几种情况要如何处理。
?? 复用领域模型
这种是最简单的情况，对应的读模型就是领域模型，要查询的数据基本上都是模型里的属性。
比如，我们有一个库存的聚合根：

文章插图
展示的数据如下：

文章插图
这个时候，就可以通过 assembler 直接转成对应的 view：

文章插图
因为聚合根和仓储是一一对应的，所以，在应用服务中直接通过 Repository 获取领域模型即可：

文章插图
?? 使用数据模型
在分页查询，或者是需要多个实体聚合查询的场景，如果直接通过 Repository 获取领域模型再组装，可能会产生很多无关查询，影响效率。
这个时候，可以根据要展示的数据直接使用数据模型，或者通过 sql 只获取指定的某几个字段。
比如，我们有 Product 和 Category 两个聚合根，它们都包含了大量的属性和业务逻辑，但是我们要展示的数据比较简单：

文章插图
这个时候就可以通过直接 sql 的形式来绕过领域模型：

文章插图
?? 使用独立的读模型
这种情况下，一般对应的查询场景都比较丰富，通常都会有一个独立的查询服务，各种数据在聚合处理之后统一放到查询服务中。
如下所示，订单在创建后，会使用 EventPublisher 来发布相应的事件：

文章插图
在订单查询服务中，会对订单创建这个事件进行监听，当收到对应的消息时，会将订单信息存储到ES里。

文章插图
如此一来，订单数据就同时存在于 MySQL 以及 ES 中。而在查询的时候会只通过 ES 。
04? 结语
在这篇文章中，我们介绍了实践领域驱动设计的时候应该如何组织代码结构、如何进行上下文的集成，以及在复杂查询场景中使用CQRS 。这些内容我同样是用脑图的形式为你总结：

文章插图
希望通过今天的讲解，你能够更游刃有余地应对开发中遇到的各种问题。但总地来说，DDD只是一种思想，所谓的分层架构也并不是事实上的标准，在实际应用时，还要结合自身的理解，可以适当地去创新或进行改进。
到目前为止，关于领域驱动设计的所有内容就都已经介绍完了。在下一篇文章中，我们会结合一个虚构的商城系统，带你实战领域驱动设计。