要結束2014年,我想到了一個簡單的問題。 我想更多地使用「DDD」,並且我正在嘗試使用各種用例來了解有關DDD的更多信息。DDD valueObject和數據庫模式
我現在用例是:
- 我們有一個使用我們公司的一個經典模式的新的數據庫模式:造型我們的命名錶作爲「ID /密碼/標籤」。例如,我認爲這是一個非常經典的例子。
但是在面向對象的世界中,當使用像JDBC或QueryDSL這樣的API時,事情就變得「合併」了。我需要通過其代碼獲取對象,檢索其id或加載完整對象,然後將其設置爲另一個對象中的一對一關係。
我想知道:
- 這種命名法的可以是一個枚舉(或具有根據顯影劑字符串cosnatnts的類)。在DDD方面,它是我的ValueObject
- 數據庫中的id/code/label不是i18n友好的(這不是先決條件),所以我沒有看到它的優點。除非動態更新表,並且用例「從該表中加載的組合框中挑選某些內容並與另一個對象建立關係:但是,這都是因爲如果您必須應用業務規則,則需要知道新代碼。等等等等)
我的問題是:
- 你經常使用的ID/OCDE /標籤圖案在你的數據庫模型
- 怎麼做你的命名數據模型(國家是?也許不是最好的例子:)但是不管你如何模型化它?沒有多想我會說國家的數據庫表;但對於某些狀態:「有效,等待驗證,拒絕」?
- 你使用這種模式建模你的valueObjects嗎?
- 或者您是否使用了大量的枚舉,並且只將toString(或ordinal)存儲在數據庫中?
在Java OO對象世界中,我目前認爲操縱從數據庫加載的對象的枚舉比較容易。例如,我需要構建存儲庫來加載它們。將它們用作枚舉將會非常簡單。我在這裏搜索一些recomfort,或者我錯過了這麼明顯的東西?
謝謝
在2015年見!
更新1: 我們可以創建一個「預算」,第一個是標記爲初始,下那些被標記爲「糾正」(與增量)。例如,我們可以有一個預算清單:「初始預算」,「糾正預算#1」,「糾正預算#2」。
爲此我們有這樣的數據庫設計:一個預算表,一個帶有外鍵的版本預算表。版本預算只包含一個ID,一個CODE和一個LABEL。
Personnaly,我想刪除此表。我沒有看到這種結構的優點。從OO的角度來看,當我創建預算時,我可以查詢數據庫以查看是否需要創建一個Inital或Corrective預算(使用計數查詢),然後我可以爲我的新預算設置正確的枚舉。但是在目前的設計中,我需要使用我想要的代碼來查詢數據庫,選擇ID並設置ID。所以是的,它確實是面向數據庫的。 DDD部分在哪裏? ValueObject是描述,量化某些事物的東西。在我看來,對我來說很好。版本描述了我的預算的當前狀態。我可以勉強兩個版本,但檢查他們的代碼,他們沒有生命週期(我不希望這個特別)。
如何處理這種類型的用例?
這只是一個簡單的例子,因爲我發現如果你問一個數據庫管理員,他肯定會說所有這些看起來都不錯:使用主鍵,建模關係,強制約束,使用外鍵和避免數據重複。
再次感謝Mike和Doctor的評論。
如果您的對象具有標識(即代碼),您將通過它檢索它,它不是一個值對象。 – DoctorMick
我對此100%確定。例如,如果我有一張內含稅表的表格。真正的基本結構可以是ID/CODE/PERCENTAGE/LABEL。在使用這種結構時,20%的稅和20%的稅之間有什麼不同?我認爲沒有。如果我們添加時態屬性,也許這可能是一個實體,但只是一個百分比和一個代碼來獲取它,是不是一個valueObject? – Archange
不,價值對象沒有身份,不存在沒有實體將其關聯的實體。這聽起來像我們正在談論參考數據,所以這可能是有用的:http://stackoverflow.com/questions/5478253/loading-a-value-object-in-list-or-dropdownlist-ddd。如果附加到某物(某個訂單或類似物)時價值沒有變化,那麼此時該訂單的稅可能是一個價值對象。 – DoctorMick