2015-02-24 40 views
3

我的應用程序中有兩個域共享相同的客戶端概念。其中一個領域是「號碼簿組件」,它負責具有與客戶有關的所有細節(即:國家,電話號碼等)。另一個領域是「提供組件」,它負責在系統中提供與提供建模相關的所有細節。可以在兩個不同的域中複製/保留相同的信息嗎?

客戶端存在於兩個域中,並且該國家最初僅用於「目錄組件」。新要求意味着客戶所在國家在「優惠組件」中的使用。

在我們的CRUD流程中,我們有一個業務邏輯,它負責協調所有適當組件(本例中爲Directory and Offers)中客戶端的創建。

我們面臨着兩個選擇:

  1. 在CRUD過程中,推動該國在「信息組件」,並堅持它在它自己的數據庫。這有一個缺點,即在更新客戶國家時需要同步多個組件中的數據(是的,它可能發生)
  2. 僅繼續堅持國家在「目錄組件」中,並依靠頂部的服務的域名來收集客戶所在的國家,並在某些業務案例需要時將其傳遞給「優惠組件」。

我們決定去與選項1,但自從我開始閱讀Eric Evans的書DDD(我仍然在這個問題上是一個新手),我質疑我們做出的決定。

任何人對此有何意見?

注意:由於設計應用程序的方式,刪除在多個組件中協調CRUD創建的服務不是一個選項。

+0

你在埃文斯讀過什麼讓你質疑這個決定?選項#1使您的系統對分區更加寬容(除非您正在使用分佈式事務),而選項#2是一致的。不知道更多,我們不能告訴你哪個選擇是正確的。 – plalx 2015-02-24 12:53:16

+0

我沒有看到選項1是錯誤的,但是從我閱讀的(沒完成),它似乎沒有針對這種問題的一些方向。我確信這是一個典型的問題,有一個理想的解決方案。 我在選項#1中質疑的一點是,每當新域需要某個值來完成它的工作時,我們需要修改創建/更新過程,並且還實現一些同步域之間數據的遷移腳本如果系統已經在生產。這非常痛苦。 – 2015-02-24 22:39:42

+0

這對於消息基礎設施來說並不是一件痛苦的事情。您不會將數據與遷移腳本同步,而是基於事件總線上發佈的事件。 – plalx 2015-02-24 22:56:19

回答

2

使用DDD時,應該將每個有界上下文分開。這可能導致在兩個BC中可能具有一些共同屬性的類似命名的類建模。系統之間的任何同步/通信和類似實體的創建可以使用應用程序級別的機制保持最新。這可能是Web服務或類似ESB(企業服務總線)的東西。如果需要,每個系統都是完整的,並擁有自己的持久性數據源(數據庫)。應用程序級別的每個系統都不應該插入另一個系統的數據庫。允許從另一個BC或外部系統直接進行數據庫操作,繞過可能存在的任何業務邏輯。

在兩本主要DDD書籍中給出的例子表明,像客戶這樣的概念在每個單獨的有界上下文中的需求會不同,並且要求客戶端在每個BC中以不同的方式建模並允許分開進化。

相關問題