建模鬆散耦合域模型

Question

這個問題並沒有真正關注DDD，但想知道是否有任何方法來模擬鬆散耦合域模型。我的意思是？我爲一個軟件HR編輯工作，我們計劃從頭開始一個新的應用程序。我們對我們爲150位客戶所做的所有項目進行了審計，事實是，從DDD的角度來看，我們不能說有一個有效的域模型。

爲什麼？因爲每個公司都以不同的方式根據公司有多大來處理人力資源等。等等。

當然，我們可以確定人力資源領域的社區實體，例如：工作，報價，合作者，技能等，但他們是對於客戶端A和客戶端B沒有以相同的方式鏈接。因此，從域模型的角度來看，我們不能說實體A具有對具有技能集合的實體B的引用，因爲它不會是對另一位顧客是真的。

即使對於我們80％的客戶，我們可以設計滿足90％需求的模型，但我們不會犧牲其他客戶，另一方面希望有一個產品可以針對特定開發進行解決不同的擔憂。

我們研究了BPM解決方案，但這不符合我們的需求。另一方面，我無法想象你能如何處理我們所需要的。事實上，實體之間的鏈接應該在運行時從每種客戶端的一種參數xml等中「完成」。我們希望不必編寫其他應用程序，因爲域模型稍有改變。這可能完全是瘋狂的，因爲沒有一個合適的領域模型，但基於消息的東西可以幫助我們。

想要你的想法。你是怎麼處理這種情況的。

感謝，

Answer 1

域模型的目的是封裝常見的行爲和關係。儘管你可以（也應該）鬆散地耦合你的實現，但是你可以通過配置驅動來實現它。

如果您繼續將其推向越來越多的可配置性，在某個點上它將不再是域模型，而是成爲框架。然後，您可以使用框架來定義特定的域模型。

編寫一個框架真的非常困難，所以我不認爲以這個明確的目標開始一個項目是一個可行的計劃。

如果可以，從一個公共的代碼庫開始，每次獲取客戶特定的請求時，都要重構內核，以便您可以將客戶功能實現爲插件。

隨着大量的時間，運氣和技巧，您可以能夠發展的內核函數爲域特定框架。

Answer 2

「神奇的產品問題」，我們所有的人都在尋找那些:)之一。我剛剛完成了一個使用SOA的成功案例。我們做了很好的識別服務的工作，後來我們稍微改變了一些編排或業務服務。

我想說的是，你將永遠無法通過配置來解決所有的差異，我應該把努力做在一個簡單的適應性良好的代碼思維，但恕我直言，「魔術產品」是不可能的。