DDD 和助手类

Question

我创建了一个基于 DDD 和六边形架构并结合 CQRS（无 ES）的应用程序。

我被困住了。

在一个有界上下文中，我有层：

• 域，
• 应用，
• 基础设施，
• UI.

我认为这是一个相当普遍的解决方案。

目前，应用程序的任何元素都没有超出其层。我相信我根据所有建议明智地分配了所有内容。

因此，我不打算在这里描述给定层中包含的内容。

但是，我很难为某些元素找到合适的位置。

那么如何处理生成 slug 和 UUID 的类？

也许我知道的太少，但根据收集到的知识，我在上述任何层中都看不到它们的位置。 另外，我不想创建类似“共享”或“通用”层的东西。 目前我停止了在应用程序中为它们创建接口的解决方案，并将实现留给基础架构。

另一件让我烦恼的事情： 我有警报实体。它负责在系统中显示通知。其中一些是根据类别随机生成的。当我使用 CQRS 时，通知生成器不是从域中获取警报，而是作为查询模型获取警报。

那么哪一层适合这样的生成器呢？这样的生成器可以被视为服务吗？

我指望帮助。

Answer 1

是的，为什么不呢。你的解决方案听起来很可靠。特别是如果应用程序不需要知道 ID 生成的性质。

例如UUIDGenerator 实现IdGenerator。应用程序中的合同仅指定它必须具有“身份”属性。

我觉得，虽然“基础架构”是其他层的所有低级实现的集合，但您的实现可能驻留在那里 - 不与外部系统通信的通用代码，而是一些“类库”代码有时被打包在一个“util”包/模块中，并直接在任何地方使用，就像在标准库中一样。

问题是——你真的需要像上面的接口-实现关系那样的动态调度吗？还是对函数 generateId 的静态调用？