用於具有多個數據庫的複合.NET應用程序的DDD/CQRS

Question

我承認我仍然是一個DDD的新手，在CQRS中更是如此。我也意識到DDD和/或CQRS可能不是解決所有問題的正確方法。不過，我喜歡校長，但在當前項目的背景下有一些問題。

該解決方案是一個模擬器，可根據當前配置生成性能數據。管理員可以創建和修改模擬規範。測試人員設置一些環境條件並運行模擬器。結果被捕獲，彙總並報告。

解決方案由3個組件區組成，每個組件區都有自己的用例，域邏輯和支持數據結構。因此，模塊化設計似乎很有吸引力，作爲分離邏輯和分離問題的一種方式。

1. 第一個區域是管理方面，它允許用戶創建和修改規範。這將是一個CRUD重型「模塊」。
2. 第二個區域將用於執行模擬。領域模型將類似於第一個領域，但爲執行模擬而優化，而不是提供便於編輯的模型。
3. 第三方面是報告。

從這我相信我有三個邊界上下文，是嗎？我有三個明確的入口點，三組域邏輯和三種不同的數據模型來支持域邏輯。

我的第一本能是遵循這些線條並創建三個封裝每個區域的域層的模塊（程序集）。我是否應該有三個獨立的數據庫？也許超過三個支持寫與讀？

我收集這可能是首選的CQRS，但我不知道如何去做。在我看來，CQRS提出了一組移動數據的後端過程。但是如果情況如此，並且數據持久性是交叉的（如DDD所示），那麼我的數據訪問代碼是否需要知道所有域對象？如果是這樣，那麼分離模塊是否有好處？

最後，我之前沒有提到的是，規範被認爲是「草案」，直到發佈，然後可用於仿真。我的PublishingService需要知道第一個和第二個領域的領域模型，以便當它響應SpecificationPublishedEvent時，它可以讀取規範，翻譯模型並將其保留以供執行。這讓我覺得我畢竟沒有三個邊界上下文。或者我在分析中錯過了什麼？

Answer 1

你可能有一個模塊化的用戶界面，但我沒有看到你所描述的必須有三個單獨的域。

首先，在CQRS報告中並不直接涉及領域模型，它是分離的Read Model的一個方面，負責呈現爲報告優化的域狀態。

其次，僅僅因爲你在域中發生的不同事情並不一定是將它們彼此分開的理由。我會通過閱讀藍色的DDD書籍來更好地感受BCs的外觀。

我不太瞭解您的域名，但我會盡量給出一些一般性建議。

從談論PublishingService的地方開始。我看到一個規範聚合根，它需要幾個可能看起來像CreateNewSpecification，UpdateSpecification和PublishSpecification的命令。

事件看起來很相似，可能會感到多餘：規範創建，規範更新，規範發佈。哪一種吸引人，但一個CRUD重型模型沒有非常有趣的行爲。我還建議找到一種自動化的方法來處理這個聚合體上的模型/模式變化，如果你不使用代碼生成，或者以不需要你的動態強調文本的方式處理變化，這將是單調乏味的。每次構建新事件。

另外，您可能會考慮不使用事件採購來處理這樣的聚合根，因爲它的CRUD很重。

您描述的第二件事似乎是開始一個模擬，它將根據規範運行並在模擬過程中生成數據（我假設）。事件驅動的體系結構在這裏有意義，以便將正在生成數據的進程的報告數據更新。如果您正在生產大量的數據進行處理，這將帶來巨大的收益。

然而，它聽起來並不像一個模擬必然是受益於事件採購的AR。一對夫婦的原因：

1. 仿真真的只需要一個命令，它是像StartSimulation
2. 模擬然後產生了它的生命時間的事件，其代表的是與模擬
3. 模擬內部不發生似乎永遠收到任何其他命令，可能取決於目前的模擬狀態
4. 模擬不是由多個客戶端/用戶同時交互，並且正如我們指出它根本沒有真正交互

一般而言，領域建模對每個單獨項目都非常具體，因此很難爲您提供構建領域模型所需的全部信息。這將是花費大量時間試圖瞭解用戶的需求以及他們試圖用軟件解決的問題的結果。當你發展他們的過程見解時，它可能會經歷多次改進。