domain-driven-design - 什么型号名称应该加上前缀

Question

我的类型命名有问题，通常它适用于我的所有项目。

我正在使用 CQRS，并且很多时候我的应用程序的不同层都引用了类似的数据“上下文”。例如，我有一个 Player 上下文，它分布在查询模型、写入模型、域模型等中。

基本上我的问题是，如果某些类/结构/数据类型专门指的是“查询”类型，我应该将其命名为 PlayerQuery 还是 QueryPlayer。

据我了解，“PlayerQuery”暗示它是对玩家数据的查询，另一方面，“QueryPlayer”暗示某种“查询”行为。

我开始编码已经有一段时间了，但我仍然在努力正确命名事物。

感觉“PlayerQuery”在这里是更好的方法。是否有任何书籍或在线资源可以解决这个问题？非常感谢

标签： domain-driven-designcqrsnaming

Answer 1

我开始编码已经有一段时间了，但我仍然在努力正确命名事物。

在这里相关的一个很好的报价：

计算机科学中只有两个难点：缓存失效和命名。

——菲尔·卡尔顿

你遇到这个问题是因为你试图用一种CRUD心态来解决这个问题，而 CQRS（或 CQS）提倡专注于实际的交互。即使应用程序的不同部分共享播放器上下文，使用它的原因也会有所不同。

例如，您将：

• 查询分页玩家列表
• 询问单个玩家的详细信息
• 保存单个玩家的数据
• 批量更新多个玩家详细信息中的属性

在每个交互中，您应该将交互本身作为提示来命名 Query/Command/DTO 对象。

所以数据类名称可以是：

• 球员名单
• PlayerDetailForQuery
• PlayerDetailForSave
• PlayerDetailsForBulkUpdate

一个改进是为每个类名加上对象类型的后缀：

• 玩家列表参数
• 球员名单结果
• 播放器行（或）播放器物品（或）播放器详细信息
• 玩家事件
• 播放器规格

最好的实现是将交互与对象类型结合起来：

• FetchPlayerList参数
• FetchPlayerList结果
• 获取播放器详细信息
• BulkUpdatePlayer参数
• 保存播放器命令
• PlayerSaved事件

最重要的是，一旦您选择了约定（例如Detail而不是Item或Row），请在整个代码中保持一致。