DDD-CQRS

什么是CQRS

CQRS: Command Query Responsibility Segregation。
CQRS理论认为对于复杂的模型展示和模型存储逻辑，将查询和命令逻辑分开会比不分开好。
这里的查询和命令模型(model)指的是内聚的、有责任模块。读写功能分开开发，并且高度内聚。
例如: 用户发起的命令逻辑(例如修改)会自动通过内存\数据库\其他通信方式(例如事件) 在查询模型中显示。

CQRS 落地实践

适用场景
CQRS 非常适合基于事件(读事件和写事件)的编程模型–>基于事件的模型往往是最终一致性的，而CQRS可以很好的在[[最终一致性]]性质下减少相关开发的复杂度。
如果 write 模型为所有更新生成事件，那么可以将模型结构化为 EventPosters，允许它们为 MemoryImages，从而避免了大量的数据库交互。
工程实践举例
编写CommandProcessor类，在该类中编写handlexxxxCommand来处理相关的事件，并且抛出该事件(yyy事件被处理了)给相关的订阅者QueryProcessor.handlexxxxEvent()。
在有相关的xxxx查询时可以调用QueryProcessor.handlexxxxQuery()来进行查询，此时Query方法内可以做缓存，不用直接读取数据库—在复杂系统了，业务一个查询请求需要请求多处存储服务(mysql、S3、Hive等)—使用CQRS编程范式可以将相关的复杂度封装到handlexxxEvent()和handlexxxQuery()里。
读写隔离
DDD对于数据存储最好使用读可以共享、写要隔离的方法开发----对数据实体的操作聚合在领域实体/领域service里，聚合根的口要小。
提供读写分离的接口(读方法们单独在一个接口里)，这样可以避免不可预知的写操作影响服务。
痛点

1. 开发复杂性风险
   这样的建模方式也可能带来复杂性风险—正如上文的事件举例，本来只需要两个方法(一个handleCommand，一个hanldeQuery，这两个hanlde可以在同一个processor里)，但是使用CQRS的方式进行编程时，需要引入handleEvent来进行处理(或者再hanldeCommand里进行处理—但这样改handle的指责就不够内聚、单一了)。

• 增加的复杂度可能给团队人员带来开发困难
• 常理来说，代码越多，bug越多

2. 编程方式改变
   建模观念的转化也是CQRS的一大痛点。传统的Processor编程(例如MVC三层模型)，一个Processor可以处理读、写操作，使用业务上下文边界来区分Processor。

总结反思

审慎的使用CQRS
使用CQRS也不要生搬硬套所谓的"最佳实践"，多和其他团队人员探讨相关实践，在不同的阶段采用不同的开发规范、方法。

参考链接

Some thoughts on using CQRS without Event Sourcing | by Marco Bürckel | Medium
martionfowler-CQRS