为应用程序命令公开强类型 ID?
Posted
技术标签:
【中文标题】为应用程序命令公开强类型 ID?【英文标题】:Exposing Strongly Typed Ids for Application Commands? 【发布时间】:2021-11-24 07:20:05 【问题描述】:我在我的域模型中使用强类型 ID,主要遵循 Andrew Lock 的指导:
https://andrewlock.net/using-strongly-typed-entity-ids-to-avoid-primitive-obsession-part-1/
这些 id,例如ProductId、CustomerId 等在 Domain Model 中声明。
我的问题是将这些暴露给应用层的消费者。目前,API 控制器可以创建一个命令发送到应用层。这些命令也需要使用 Id。我当前在 Command 对象中的实现是使用原始类型 Guid,然后在调用域模型上的方法时创建一个强类型 Id。
但是,通过使用强类型 id 提供的控制来扩展 API 控制器和应用程序层之间的通信是有意义的。但是,我不希望我的 API 控制器引用域模型(这是目前声明强类型 ID 的地方)。
如何解决这个问题?
从应用层声明一组类似的强类型 ID。但这仍然需要在调用域中的方法之前在应用程序声明和域模型声明之间进行转换。
将 Id 的声明移动到 API 和域模型都可以引用的“公共”模块中。但这意味着域模型依赖关系会泄漏到 API 控制器依赖关系中,并且我的域模型方法中的任何更改都可能影响 API 控制器,这是不可取的。
这个问题似乎是合理的,但上述解决方案都不是最佳的。有什么想法吗?
【问题讨论】:
【参考方案1】:阅读过 Vaughn Vernon 的《实施领域驱动设计》一书:
https://www.amazon.co.uk/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577/ref=asc_df_0321834577/
我遵循了第 580 页的建议,基本上是“务实”。
具体来说,
对于我认为非常“固定”的 Id 和任何其他值对象,我选择使用 API、应用程序和域层可以使用的共享内核(即我的问题中的选项 2)。
对于其他可能更复杂的值对象,这些对象可能包含特定于域的额外业务逻辑并且可能会因业务变化而更加不稳定,然后我使用我的问题中的选项 1 并创建一个精简 (DTO)用于从应用程序公开并执行从这些版本到域模型版本的映射的版本。
【讨论】:
以上是关于为应用程序命令公开强类型 ID?的主要内容,如果未能解决你的问题,请参考以下文章