2012-07-30 34 views
0

我正在努力處理下面的域設計,因爲我理解它們不符合DDD的概念。一方面,我有設備 - >傳感器 - >測量層次結構,建模爲帶有設備的聚合,作爲根,傳感器作爲實體,測量爲VO。到現在爲止還挺好。建模兩個並行的聚合,實體和值對象層次結構

現在,每個設備都有一個類型,傳感器也是如此。同時,測量是指測量的變量(例如溫度)。這裏是分開的地方。

我最初將類型建模爲值對象,但有一組類型,許多設備和傳感器共享相同的類型。

然後我決定將它們建模爲一個聚合體,遵循與設備聚合體類似的結構:DeviceType-> SensorType-> Variable。但是,這不起作用,因爲傳感器可能會引用SensorType和Measurement to Variable,從而違反了僅允許從另一個聚合中引用聚合的根的規則。此外,可能發生的情況是,多於一個的DeviceType包括相同類型的傳感器(例如電池充電傳感器),並且多於一個傳感器測量相同的變量(例如電池充電水平)。

這導致我將這些實體(DeviceType,SensorType,Variable)中的每一個作爲獨立的實體,每個實體都是它自己的(退化的)。

我的具體問題是:我是否正確地解釋了Aggregate,Entity,VO的概念,還是將這種貧血的聚集體完全根植於反模式?

+0

我認爲這會有幫助,如果你發佈了一些你到目前爲止的代碼。 – eulerfx 2012-07-31 00:09:29

+0

到目前爲止還沒有代碼。我仍然在對域進行建模。我試圖提交一個圖像,但系統不允許我這樣做,因爲我是一個新用戶。 – pablochacin 2012-07-31 04:47:16

+0

pablochacin,你有沒有想出一個適合你的域名建模的方法?我也有類似的情況...... – oakman 2015-01-05 11:24:28

回答

0

在建模中沒有硬性規定,你應該儘可能適合你的用例。話雖如此,聚合主要用於維護一組實體的不變量。我在DeviceType,SensorType和Variable之間沒有看到任何這樣的約束,因此我沒有看到任何將它們放入聚合的理由。將它們保持爲獨立的實體(甚至是值對象)應該沒問題。

+0

不像Device Objects和Varibale那樣對值對象進行建模的一點是,它們不是像典型地址示例那樣簡單屬性的Device Sensor和Measurement(分別)。它們被定義爲系統配置的一部分,然後由其他實體引用。這讓我感到困惑。 我想,正如你所指出的,也許他們應該被視爲獨立的實體。 – pablochacin 2012-08-01 06:40:15

+0

@pablochacin:在這種情況下,是的,你可以將它們建模爲實體,但保持獨立。擁有不屬於聚合的實體沒有任何錯誤。 – casablanca 2012-08-02 01:46:58