DDD對價值對象和實體和字典類型的建模

我想將我的問題提供給更多的受衆，因爲我們已經在公司討論了一段時間，並且找不到答案。DDD對價值對象和實體和字典類型的建模

讓我們假設我們有交易是聚合根的對象。 Inside 交易我們有Money這是價值對象。

class Transaction { 
    private Money money; 
    // other stuff 
}

和

class Money { 
    private BigDecimal amount; 
    private String currency; 
}

這種交易可以持久（我們使用休眠），以分貝爲簡單的表交易

+-----------------+ 
| transaction  | 
+-----------------+ 
|id : bigint  | 
|amount: decimal | 
|currency: varchar| 
|other...   | 
+-----------------+

所有的一切都將是巨大的，但..客戶要求我們在數據庫中有貨幣表（我們稱之爲字典表）和每個表（in。）結束性交易）有資金需要指向貨幣表：

+-----------------+   +-----------------+ 
| transaction  |   |curency   | 
+-----------------+   +-----------------+ 
|id : bigint  |  +---> | id: bigint  | 
|amount: decimal |  |  | code: varchar | 
|curr_id: bigint | ----+  | name: varchar | 
|other...   |   +-----------------+ 
+-----------------+

所以從現在開始，貨幣對象應該是這樣的：

class Money { 
    private BigDecimal amount; 
    private Currency currency; 
}

而且從現在開始，我們不能把它的值對象：（或者我們可以嗎？它也使我們堅持對象的方式複雜化，因爲我們不能再使用hibernate進行嵌入，因爲我們需要編寫我們自己的定製類型。當然，我們不是第一個面臨這個問題的人，因爲字典類型在使用中很受歡迎，問題是，如何在ddd建模的範圍內對待它們。

我們在處理地址時會遇到類似的問題。所以，我們知道我們有像Country和FederalState這樣的詞典（它們是分層的）。而且我們也知道我們應用程序中的許多對象（例如機構）擁有自己的地址，但也與FederalState有聯繫。因此，在simpe情況下，我們將有：

class Institution { 
    Address address; 
    // ... 
}

其中

class Address { 
    String street; 
    String houseNo; 
    // etc.. 
    String federalState; 
    String country; 
}

但我們需要它有關係fedral狀態表，因此地址類似於：

class Address { 
    String street; 
    String houseNo; 
    // etc.. 
    FederalState federalState; 
}

，所以我們再次面對同樣的問題，從現在開始Address不是值對象。我們知道如何在技術上做到這點，但從od ddd的角度來看，正確的做法是什麼？

來源

2016-10-05 dsinczak

」從現在我們不能稱之爲價值對象:(「 - 爲什麼？ – guillaume31

@ guillaume31因爲現在它有自己的表，它獲得了更高的地位，它可能會感到冒犯？ –

我看不到Money表在你的問題的那一點。此外，決定一個對象是否是一個Value對象與數據庫表沒有什麼關係 – guillaume31

「什麼是從這個角度OD DDD正確的方法」

首先，利用字典實體是沒有錯的。無論是僅針對不像一個字符串值，使用關係到詞典實體的原因：

避免錯別字（更健壯）
允許管理組「價值」，而不在代碼修改 - 您只需從存儲中加載字典並填充下拉列表，而不是在代碼中定義Enum（更靈活）。

撇開上述兩點，業務需求可能會強加這種設計。例如。對於Currency的情況：當表達爲一個實體時允許定義Exchange Rate關係，它本身可能會受到一個'auditable record/history'方法的影響，用於存儲exc.rate隨時間的演變。
擁有State字典是處理不同銷售稅收政策或立法限制（產品/服務在某些州不允許的產品/服務 - 請參閱'藥用'雜草以及不是什麼）的很好的基礎（可能的未來）。「

來源

2016-10-05 13:06:07

DDD對價值對象和實體和字典類型的建模

回答

相關問題