用於同步共享域模型的設計模式

雖然我熟悉四人幫中所描述的設計模式，但在企業級別上，將會出現很多我從未聽說過的模式。希望有一個能夠激發我在工作中遇到的問題的解決方案：用於同步共享域模型的設計模式

我有三個一起工作的應用程序。我們稱他們爲ApplA，ApplB和ApplC。他們共享一些領域模型，例如類MyEntity

public class MyEntity 
{ 
    public Guid ID {get;set;} 
    public string Name {get;set;} 
    //other properties 
}

用戶可以使用ApplA重命名這樣的對象。當發生這種情況時，應在和 ApplB和ApplC中進行操作。這是通過使用排隊（卡夫卡，但排隊系統的選擇可能無關緊要）啓用。遵循快樂的道路，這兩個應用程序都會從隊列中選取消息並執行各自的操作。

但是，替代路徑是ApplB或ApplC在處理隊列中的消息時失敗。假設應用程序ApplB失敗，則ApplC不應執行其操作，或者撤銷其操作。有沒有關於如何解決這些問題的模式/指導。

編輯：在上面的文字中，我談到了重命名MyEntity，但我看到這個語句如何被誤解。重命名後，我不打算更改類名稱，而是重命名MyEntity類型的對象（請注意屬性名稱）。所以爲了給出一個更好更明確的例子，考慮多個應用程序使用一個Person實體。

public class Person 
{ 
    public Guid ID {get;set;} 
    public string FirstName {get;set;} 
    public string LastName {get;set;} 
    //other properties 
}

如果一個人改變姓氏（當女性在荷蘭結婚，它仍然是常見的做法來把握自己的丈夫的姓），所有相關的應用程序必須執行一些業務邏輯。請注意，這不僅僅是更新一個數據庫的問題，更多的業務邏輯必須執行。現在，如果其中一個應用程序在其他方面取得成功時失敗，那麼採用何種模式/編程實踐來解決這個問題？

來源

2017-07-18 SimonAx

設計模式適用於同一應用程序中的代碼。沒有什麼是跨應用程序。您對三種應用程序的工作方式進行了描述，類似於**責任鏈**模式，但同樣只適用於同一應用程序中的代碼。考慮將這三個應用合併爲一個。 –

三個應用程序中的兩個是獨立的產品，我們不直接開發自己，我們只創建了插件。因此合併應用程序不是一種選擇。 – SimonAx

什麼插件？在我看來，你的應用程序正在調用其他兩個應用程序？如果是這樣的話，那麼你可以在你的應用中使用**責任鏈**模式來控制你如何調用其他兩個應用。 –

既然你提到領域模型作爲方法的一部分，我會提出一個patterns for context mapping in the context of DDD (domain-driven design)的答案。域模型對於不同的上下文（應用程序）可能相似或可能不相似。你可以閱讀更多關於鏈路上的每個模式，但在這裏，他們是：

共享內核
客戶/供應商開發團隊
循規蹈矩
反腐敗層
各路

如果我沒有弄錯，Apache Kafka是一種「反腐敗層」。

域模式超出了GoF（軟件類模式）的範圍，因爲建模處於不同的級別。

關於您的「重命名」問題，很難說您什麼時候不提供更多關於重命名類的更多細節，以及其他應用程序對名稱的假設。在應該在大學工作的應用程序中將「學生」的域名類重命名爲「魚」是沒有任何意義的。它真的很多次都取決於具體情況。

來源

2017-07-18 20:13:24 Fuhrmanator

@SimonAx如果某人更改了名字，並且某個應用未能自行更新，則需要使用容錯模式來處理此問題。羅伯特漢默有一本書。某些模式甚至涉及人爲干預，例如，操作員可以手動更正失敗應用上的重命名，或者從其他應用中撤消該模式。還有自動化解決方案。 – Fuhrmanator

用於同步共享域模型的設計模式

回答

相關問題