面向领域驱动架构的查询实现方式

面向领域驱动架构的查询实现方式

在传统的分层架构里，查询操作往往被简单粗暴地塞进Repository或Service层，导致业务逻辑与数据访问逻辑纠缠不清。而在领域驱动设计（DDD）中，查询的实现有着更精细的考量------因为查询不改变系统状态，不需要承载复杂的业务规则，这与命令（Command）的职责完全不同。本文将从DDD的视角，聊聊查询的几种实现姿势，以及它们的适用场景。### 一、为什么查询在DDD中是个"特殊存在"？DDD的核心是领域模型，它负责表达业务规则和状态流转。但查询（Query）通常只是"读数据"，不改变任何状态，也不触发领域事件。如果强行用领域模型去实现查询，往往会遇到两个麻烦：1. 性能瓶颈 ：领域模型需要加载完整聚合，但查询往往只需要部分字段，加载过多数据会拖慢响应。2. 模型污染 ：为了适配查询需求，我们可能会在聚合上添加一些只用于展示的方法，这会让领域模型变得臃肿。因此，DDD社区普遍建议：将查询与命令分离 。命令走领域模型，查询走专门的查询路径。### 二、查询的三种实现方式#### 1. 基于仓储（Repository）的查询这是最基础的方式，适用于需要返回完整聚合根的场景。比如，你正在做订单系统，需要根据订单ID获取订单详情，用于后续的修改操作。python# order_repository.pyfrom typing import Optionalfrom .order import Orderclass OrderRepository: """订单仓储，用于聚合根的持久化与重建""" def __init__(self, db_session): self._db = db_session def find_by_id(self, order_id: str) -> Optional[Order]: """根据ID获取订单聚合根""" # 这里会加载订单以及其下的所有订单项 row = self._db.execute( "SELECT * FROM orders WHERE id = ?", (order_id,) ).fetchone() if not row: return None # 重建聚合根（这里省略了子实体的加载逻辑） return Order( id=row['id'], customer_id=row['customer_id'], status=row['status'], items=self._load_order_items(order_id) )这种方式的优点是保持了聚合的完整性，适合写操作前的数据准备。但缺点是如果查询只需要订单的"客户名"和"总金额"，加载整个聚合就有点"杀鸡用牛刀"了。#### 2. 基于查询服务（Query Service）的投影查询当查询不需要完整聚合时，更推荐使用查询服务。它直接读取数据库表或视图，返回轻量级的DTO（数据传输对象）。这种方式特别适合列表页、报表等展示场景。python# order_query_service.pyfrom dataclasses import dataclassfrom typing import List@dataclassclass OrderSummary: """订单摘要DTO，只包含展示所需字段""" order_id: str customer_name: str total_amount: float status: strclass OrderQueryService: """订单查询服务，不经过领域模型，直接读数据库""" def __init__(self, db_connection): self._db = db_connection def get_recent_orders(self, limit: int = 10) -> List[OrderSummary]: """获取最近订单的摘要列表""" # 使用SQL投影只取必要字段，避免加载完整聚合 rows = self._db.execute(""" SELECT o.id as order_id, c.name as customer_name, SUM(oi.price * oi.quantity) as total_amount, o.status FROM orders o JOIN customers c ON o.customer_id = c.id JOIN order_items oi ON o.id = oi.order_id GROUP BY o.id ORDER BY o.created_at DESC LIMIT ? """, (limit,)).fetchall() return [ OrderSummary( order_id=row['order_id'], customer_name=row['customer_name'], total_amount=row['total_amount'], status=row['status'] ) for row in rows ]这种方式的好处是：- 性能优化 ：按需取字段，减少数据库IO和网络传输。- 解耦 ：查询逻辑不依赖领域模型，便于独立优化和测试。- 灵活 ：可以针对不同的查询场景设计不同的DTO。#### 3. 基于CQRS的专用读模型如果你的系统比较复杂，读操作和写操作的性能要求差异很大（比如写少读多，且读场景多样化），可以考虑引入CQRS模式。它将读写模型彻底分离，读模型可以通过事件同步、物化视图或NoSQL来构建，专门为查询优化。python# read_model_updater.pyclass OrderReadModelUpdater: """监听领域事件，更新读模型（例如Redis或Elasticsearch）""" def __init__(self, event_bus, read_db): self._event_bus = event_bus self._read_db = read_db # 订阅订单相关事件 event_bus.subscribe("OrderPlaced", self._on_order_placed) event_bus.subscribe("OrderStatusChanged", self._on_status_changed) def _on_order_placed(self, event): """订单创建后，在读模型中写入一条摘要记录""" order_summary = { "order_id": event.order_id, "customer_name": event.customer_name, "total_amount": event.total_amount, "status": "PLACED", "created_at": event.timestamp } # 写入读数据库（例如Redis的Hash结构） self._read_db.hset(f"order:{event.order_id}", mapping=order_summary) # 也可以更新一个用于列表查询的索引 self._read_db.zadd("recent_orders", {event.order_id: event.timestamp})CQRS的读模型可以做到：- 极致性能 ：预计算好查询结果，响应时间极短。- 可扩展性 ：读模型可以独立水平扩展，不影响写模型。- 场景定制 ：可以为不同查询场景构建不同的读模型（比如一个用于手机端，一个用于Web端）。但代价是引入了最终一致性，且系统复杂度显著增加。如果业务不是特别需要，不建议轻易上CQRS。### 三、如何选择？我建议你按以下优先级来决策：1. 绝大多数场景 ：优先用仓储查询。只要查询返回的是完整聚合，且不会引发性能问题，就老老实实走仓储。2. 列表/报表/轻量展示 ：用查询服务+DTO。这是最常用的组合，性价比最高。3. 特定场景有硬性性能要求，且读模型可以容忍最终一致性 ：才考虑CQRS。另外，无论选哪种方式，都要注意一个原则：查询不修改领域状态 。不要在查询方法里偷偷调用save()，不要因为查询需要而给聚合添加"副作用"方法。### 四、总结在DDD架构中，查询的实现方式反映了我们对"读"与"写"分离的理解程度。仓储查询保持了领域模型的完整性，适合写操作；查询服务轻量灵活，适合展示场景；CQRS则提供了极致的读性能，但需要付出架构复杂度。实际开发中，我建议先从仓储和查询服务入手，只有当查询需求变得复杂且性能瓶颈明显时，才考虑引入CQRS。记住，没有银弹，最好的架构是"够用"且"可演进"的。希望这篇文章能帮你在DDD的查询之路上找到自己的节奏。