【发布时间】:2015-05-14 16:28:31
【问题描述】:
你如何处理 DDD 中的 url slug 生成?
在构造函数内部?但是依赖其他服务的实体不好。
作为构造函数参数传递?我认为蛞蝓不应该在那里,因为它们不是业务需求。是吗?
还是只有一个二传手?
【问题讨论】:
-
slug 看起来不像是来自您的底层业务领域的真正概念,而是为 Web 应用程序提供漂亮 URL 的东西。因此,slug 生成是另一层或有界上下文的一部分,不属于核心域。
-
您将如何处理?我们有课程,我希望课程的标题是 url 而不是 id。 url 可能会因标题而异,如果它太长或出于其他原因,所以我认为最好将其保存在数据库中。所以你的意思是有界上下文,我应该把它保存在单独的表上?
-
是的,单独的表可能是最好的主意。最后,slug 只是一个演示问题,如果你曾经在课程系统中添加一个移动应用程序,那么 slug 在这里没有任何意义。
-
谢谢。还没有机会玩它。
-
我知道这很难,但我认为 url slugifier 作为服务在域层之外,今天你可能会使用外部包来生成它,明天你可能会使用外部 API,我不会将此逻辑放在域中。因此,就像@AlexanderLanger 所说,我将创建一个带有 url slug 的分隔实体,以及对所有者实体(id 和类型)的引用。因此,您可以为任何类型的实体(图像、视频)存储 url slug。将属性放在实体中是很强大的,就像它是实体的部分,独立于用于使用所述实体的应用程序。
标签: entity domain-driven-design slug