DDD：如何處理存儲在多個存儲系統中的一個實體？

我目前正在將遺留應用程序遷移到域驅動的設計模型，我遇到了這個問題：該應用程序是關於實時管理大量聯繫人，包括檢查重複項。每當有人保存一個新的聯繫人時，它必須通過一個第三方軟件（它基本上是一個相似性搜索軟件）的重複檢查。如果通過檢查，聯繫人將在SQL中創建，聯繫人的一小部分（與重複檢查相關的一些核心字段）必須存儲在第三方軟件的數據庫中。所以實體「聯繫人」生活在兩個（同步）存儲系統中，但一個系統只有一小部分字段，而SQL有50個以上的聯繫人字段。DDD：如何處理存儲在多個存儲系統中的一個實體？

現在我在想是否可以爲「聯繫」（Contact和ContactShort）創建兩種類型。因此，我還必須爲這些實體創建兩個存儲庫，並將這些存儲庫用於最終用於執行那些需要重複檢查軟件（如保存/插入方法）的操作的域服務中。

如何處理這種情況有一個很好的經驗法則嗎？

編輯：我仍然沒有找到一個明確的解決方案，但想到更多關於它：也許在這種情況下，將重複檢查存儲系統與SQL DB分開是錯誤的。其實，我認爲揭露第三方軟件的方法是錯誤的。這是純粹的基礎設施。由於保存操作決不能在沒有重複檢查的情況下執行，我認爲對第三方軟件的調用應該在SQLRepository的內部。它絕不能離開基礎架構層，因爲它永遠不會返回聯繫人的有效實體。你怎麼看？

來源

2011-06-12 hoetz

相關：http://stackoverflow.com/questions/4355860/implementing-set-based-constraints-in-cqrs – 2011-06-13 19:08:42

對我來說你的建議解決方案聽起來不錯。在較低級別（數據訪問層），您應該有兩個獨立的對象，它們可以訪問兩個不同的數據庫（兩個存儲庫，因爲您需要不同的連接字符串）。如果使用相同的數據庫引擎，則可以是同一個XXXRepository的兩個實例，或者它可以是不同的存儲庫XXXRepository和YYYRepository來訪問2個不同的數據庫引擎）。

但是，在上層（域層和GUI），不應該對這些數據的方式和位置感到困擾。正如你所說的，你有一種服務將管道分離，以便應用程序域和上層（如GUI）不會看到下面發生的事情（在數據訪問層中）。

來源

2011-06-12 13:13:37 oleksii

你是什麼意思的「下一級」和「上一級」？較低級別是域層中定義的存儲庫接口的具體實現？ – hoetz 2011-06-13 05:34:56

@Malkier對不起，我擴大了我的答案。在較低級別下，我的意思是數據訪問氾濫，高層次是任何高於這個水平的業務邏輯和GUI。較低級別將有兩個存儲庫，但您將通過服務訪問它們。只有該服務會知道如何使用2個存儲庫操作數據，因此您可以將域從存儲層中隱藏起來。這是我的看法，因爲它是錯誤的。 – oleksii 2011-06-13 07:45:52

我編輯了一個新想法的問題，看看。 – hoetz 2011-06-18 13:37:27

DDD：如何處理存儲在多個存儲系統中的一個實體？

回答

相關問題