領域驅動設計中的設計模式實現

Question

我正在使用 DDD 和六角架構構建一個應用程序，以 Typescript 作為主要語言。

最近我有一個問題需要觀察者設計模式實現來解決。

現在解決了，我想重構它，首先想到的是移動它，因為我已經把它放在 Domain 層，因為有 2 個接口和 2 個不使用任何第三方庫的接口實現.

即使他們沒有使用第三方並且不知何故沒有被外部系統“污染”，但將它們放在領域層中感覺很糟糕，因為這不是領域問題。

我曾想過將它們一起放在域之上但基礎設施之后的應用層中。 我只是不想在第一次實現它們時就猜測這類事情，並且想知道它們通常放置在哪里。

Answer 1

事實上，有些代碼似乎不太適合標准化的域/基礎設施/應用程序層。 一般而言，諸如字符串實用程序（例如Strings class）、列表實用程序（例如Lists class 等）之類的擴展標准庫的代碼不會在體系結構中找到自然歸宿。

如果您有一個具有多個限界上下文的整體，那么在根目錄下創建一個common或shared模塊並將它們放在那里可能是有意義的。 這就是 Vaughn Vernon 在IDDD 示例中所做的。 這將被視為 DDD 術語中的 SharedKernel。 請注意，我 100% 確定 SharedKernel 是整個公共模塊，還是僅僅是域 model 的共享部分。由於“共享內核”描述了限界上下文之間的一種關系，所以我會說它是整個事情，但有些人似乎不同意。 例如

我想澄清一下，這與共享 Kernel 不同，我在之前關於域驅動設計的博客文章中介紹過。 不同的是，Shared Kernel 是Domain層的公共庫，包含跨限界上下文共享的公共基類、領域實體、值對象等。 https://blog.jacobsdata.com/2020/02/19/a-brief-intro-to-clean-architecture-clean-ddd-and-cqrs

如果你只有一個 BC，你仍然可以用同樣的方式提取它，或者你可以在 BC 中有另一個層（例如util ， seedwork ），這實際上不是架構的一部分。

請注意，重要的是不要成為嘗試開發將在許多項目中使用的可重用庫/框架的犧牲品，因為這會使更改和發展變得更加困難。 有時復制和改編比分享更有意義。 這個概念通常稱為SeedWork 。