2014-12-31 49 views
1

要結束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的評論。

+1

如果您的對象具有標識(即代碼),您將通過它檢索它,它不是一個值對象。 – DoctorMick

+0

我對此100%確定。例如,如果我有一張內含稅表的表格。真正的基本結構可以是ID/CODE/PERCENTAGE/LABEL。在使用這種結構時,20%的稅和20%的稅之間有什麼不同?我認爲沒有。如果我們添加時態屬性,也許這可能是一個實體,但只是一個百分比和一個代碼來獲取它,是不是一個valueObject? – Archange

+0

不,價值對象沒有身份,不存在沒有實體將其關聯的實體。這聽起來像我們正在談論參考數據,所以這可能是有用的:http://stackoverflow.com/questions/5478253/loading-a-value-object-in-list-or-dropdownlist-ddd。如果附加到某物(某個訂單或類似物)時價值沒有變化,那麼此時該訂單的稅可能是一個價值對象。 – DoctorMick

回答

0

我會掛在你的國家的例子。在大多數情況下,國家將是一個價值對象。沒有什麼會提及一個國家實體,並且應該知道,如果國家的價值觀改變了,它仍然是同一個國家。事實上,這個國家可以被視爲一個枚舉,以及一​​些令人討厭的資源查找功能,可以將Iso3轉換爲有用的顯示文本。我們所做的是,我們將它定義爲一個具有iso3,displayname和一些其他靜態信息的值對象類。現在,從這個值對象中我們定義了一種「權力枚舉」(我仍然錯過了一個標準術語)。實現國家/地區值對象的類爲其每個值(每個國家/地區)和顯式轉換運算符從/到int獲取私有構造函數和靜態屬性。現在你可以把它看作是你的編程語言的正常枚舉。除了具有更多屬性字段之外,普通枚舉的優點是,它也可以具有方法(當然,查詢方法不會更改對象的狀態)。你甚至可以使用多態(一些國家的行爲與其他國家不同)。您也可以從數據庫表中加載枚舉的內容(而不是靜態然後使用靜態lookupByIso3方法)。

這也可以與其他「enum like」值對象一起製作。想象一下貨幣(它可能有實現多態的轉換方法)。儘管如此,處理每日匯率是一個不同的話題。

如果這組值不固定(例如郵政地址等其他值對象候選),則它不是值對象枚舉,而是可以使用所需值實例化的標準值對象。

要決定您是否可以像某個值對象一樣生活,您可以使用以下問題:您想要複製語義還是引用語義?如果您更改過該對象的屬性,那麼您使用它的所有地方是否也要更新,還是應該保持原樣?如果後者比「已更改」對象是新的不同值對象。另一個問題是,如果你需要追蹤一個對象的變化,意識到它仍然是「相同的」,儘管它改變了值。如果你有一個值對象,你只想要特定的實例存在,它就是上面描述的一種枚舉類型。

這是否幫助你?

+0

國家可能擁有大量屬性,例如電話代碼,貨幣,時區,語言,歐盟成員,增值稅號碼前綴等。那麼你怎麼能確定你永遠不會需要這個? –

+0

我認爲在DDD中,你不會模擬你可以從現實中想象的所有屬性的國家,而只是有界的上下文需要的屬性。在另一個有界的環境中,你可以使用其他需要的屬性對它進行建模。你所描述的事情也是不同的概念,而不是簡單的國家屬性。我所說的「國家」就是國家本身。不像人口統計。但即使你必須改變它的一些屬性,問題仍然是如果這需要在此之後是「相同的」,或者如果你可以把它作爲一個「新」的價值。 –