0

我创建了一个基于 DDD 和六边形架构以及 CQRS(没有 ES)的应用程序。

我被困住了。

在有界上下文之一中,我有层:

  • 领域,
  • 应用,
  • 基础设施,
  • ui。

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

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

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

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

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

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

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

那么哪一层适合这样的生成器呢?这样的发电机可以被视为一种服务吗?

我指望帮助。

4

1 回答 1

1

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

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

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

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

于 2020-10-29T20:04:49.220 回答