我正在設計Web應用程序的基礎體系結構。該項目遵循Domain-Driven Design方法,因爲業務模型和邏輯非常複雜。服務層和模型與域驅動設計的關聯
該項目還旨在成爲一個SOA項目(面向服務的體系結構)。所以我正在學習很多關於服務以及如何圍繞它來構建項目。
在previous question of mine之後,我有一個關於模型類中的關聯的問題。
我明白,模型類不應該知道和做任何有關持久性。然而,我很難決定模型類之間的關聯。
例如:
- 類
Person
- 類
Car
有(爲例子)
一個驅動程序getDriver
和getCars
應放在何處?
- 在模型類:
$car->getDriver()
與原始類型服務層
- :在服務層
$personService->getPerson($car->getDriverId())
- 使用OOP:
$carService->getDriver($car)
溶液1似乎更自然。我正在使用Doctrine 2,因此模型關聯會使用數據庫映射註釋處理。這樣,模型不會做任何與持久性相關的事情(儘管實際上通過Doctrine來做)。這是我最喜歡的解決方案,但除了加載「汽車」列表之外,本服務的重點是什麼?因爲它扔掉OOP和型號/服務的用戶必須知道有關數據庫模型獲取協會(他已經知道這ID是一個「人」的ID)
解決方案2.似乎只是愚蠢。他必須親自去做這個協會。
解決方案3比解決方案2好一點,但仍然是其中OOP在那?
所以,對我來說解決方案1.是最好的。但我已經看到了解決方案2和解決方案3在實際項目中使用(有時混合在一起),所以我有疑問。
而且,問題就變成當有額外的參數比較複雜,例如:
$person->getCars($nameFilter, $maxNumberOfResults, $offset);
(在這種情況下,它確實看起來像一個SQL查詢/持久查詢)
那麼,哪一個應該用於模型/服務體系結構上的項目跟在域驅動設計的方法?有了SOA,我的模型應該只是沒有邏輯的「啞」數據容器嗎?如果是這樣,那麼DDD方法在哪裏?
確定首先我明白我混合了SOA和應用程序服務。實際上,所有關於關聯的問題都依賴於一個實體是否是一個聚合根。如果是,我應該使用存儲庫。如果它是一個聚合的子實體,那麼我應該使用對象關聯。我對麼? –