域驅動設計：經理和服務

Question

我在應用程序中創建一些業務邏輯，但我不知道如何或在哪裏封裝它，我已經使用存儲庫模式進行數據訪問，我見過一些項目使用帶有「服務」後綴和「經理」後綴的一些類的DDD，這些類別中的每一個都應該在DDD中處理哪些內容？

Answer 1

不要太注意命名;一般來說，服務爲類提供了一些東西以減少耦合，而且管理者更一般化 - 可能是跟蹤其他對象和/或狀態的類。

對DDD方法更重要的是對域進行實際建模。這很大程度上取決於您的行業（或您的應用所針對的行業）以及您正在構建的應用程序的類型。 「在哪裏封裝？」是此過程中的基本推動力，但主要歸結爲創建真實世界實體的類別表示：員工，客戶，供應商，發票，交易，報價，合同等。

服務和經理可能會幫助您在運行時將這些東西粘合在一起，並且該命名有助於將這些類與封裝域邏輯的東西區分開來。

Answer 2

如果您決定使用領域模型模式（顯然，如果您想要執行DDD），業務邏輯（例如驗證，計算和業務規則）絕對構成領域模型的一部分（您的業務對象和關係物）。

一個很好的一般參考也可能會給你馬丁福勒書'Patterns of Enterprise Application Architecture'。

Answer 3

儘量使名稱儘可能具體。作爲一個經驗法則，我會avoid the name "Manager"，因爲它的含義很模糊。

典型的業務邏輯參與者將是驗證者，規則，供應商，主管，進口商/出口商，串行器，處理器（處理事務）和存儲庫（最後一個已有）。如果一個類正在執行多個這些功能中的一個，則應該將其分解爲子類。

你問了這個問題：「這些課程關心什麼？」事實上，這就是要點。名字SomethingManager沒有告訴你什麼。另一方面，OrderValidator與CustomerHistoryExporter一樣，非常清楚地告訴你班上的工作情況。服務類似於灰色地帶;如果服務以被動操作命名，如ShippingService，那麼服務處理的內容很清楚，但更好的名稱可能與ShipmentDispatcher類似。你明白了，我希望。