DDD微服务

Cri*_*sta 1 architecture design-patterns domain-driven-design

几周前我一直在研究 DDD 模式,但我没有得到一个问题的答案。

按照 Eric Evans 的原则,Domain 模块不应该与其他模块、包或任何东西有任何依赖关系。这里应该包括所有模型,如错误、实体、接口......

我的问题是,例如,如果所有微服务之间共享一个错误模板,是否应该在每个微服务上重复相同的对象?

我认为这为项目提供了很棒的模块化,因为它没有外部依赖项,但可扩展性很差,因为在任何更改时都必须更改每个微服务。

你有没有想过这个问题?谢谢。

SKl*_*ous 5

该指南旨在:

  1. 不要让您的域依赖于共享库。这将阻碍一个领域的发展(和变化),因为它会破坏另一个领域的行为。
  2. 帮助我们确保我们不会跨域重复业务行为。这是非常重要的。
  3. 不要让您的域依赖于基础设施。我强烈怀疑,在人们过去将域逻辑放入存储过程中的时候,这要重要得多,但今天它仍然非常重要,因为它确保逻辑与存储库、存储等隔离并独立。使它非常易于测试。

考虑到上述情况,可以理解一些共享是可以的。事实上,您已经在分享一些东西:基本的语言结构和基类库。共享一些帮助程序库绝对没问题,而且确实在某些情况下,这样做非常有帮助。这样做时你应该非常小心:

  1. 以共享帮助程序库的形式共享业务逻辑违反了上述第一条规则,因为业务逻辑可以随着我们对域的理解而改变。
  2. 共享特定于域的数据结构违反了上面的第一条和第二条规则。当我们对域的理解发生变化时,特定于域的数据结构可能会发生变化,并且拥有多个依赖于它们的域会阻碍这一过程。它也违反了第二条规则,因为特定于域的数据结构隐含地携带行为。

特别是在您的情况下,这实际上取决于错误模板是什么:

  • 它是否类似于某些确保异常包含一些在调试中有用的基本信息集并且不包含任何特定于域的数据结构的数据结构?如果是这样,那应该没问题。
  • 它是否接受特定于域的数据结构?然后我会说这不好
  • 它是否包含任何特定于域的行为来解释某些特定于域的数据并填充模板?然后又没有。