域服務是域模型的一部分嗎？

Question

根據DDD，服務是域模型的一部分嗎？如果我們google爲「ddd洋蔥體系結構」，我們可以看到最內層被稱爲「域模型層」，第二層是「域服務」，例如http://tidyjava.com/onion-architecture-interesting/。但是在https://en.wikipedia.org/wiki/Domain-driven_design和DDD書中，我們看到那些實體，價值對象和服務都表達了模型並且是模型元素。如果實體，價值對象和服務都是領域模型的一部分，我們應該如何將這兩層洋蔥叫做：模型（實體+價值對象）和服務（我有時候會這樣做）？但是如果所有的都是域模型的一部分，這個命名看起來並不準確。

Answer 1

域服務是域模型的一部分嗎？

是的，但也沒有。

在the blue book中，域服務在第5章中描述;立即在實體和值類型之後。埃文斯寫道：

在某些情況下，最清晰和最實用的設計包括操作，不在概念上屬於任何對象。我們可以遵循問題空間的自然輪廓，並在服務模型中明確包含服務，而不是強制解決問題。...

服務是一種操作，它是一種獨立於模型中的接口，不包含任何狀態....

接口是根據域模型的其他元素定義的。

但它不會永遠是域名服務實施生活領域模型本身的情況。

在某些情況下，域服務實際上充當服務提供者，需要連接到基礎結構以執行其角色（例如，將消息發送到另一個進程）。因此，領域模型定義了提供者接口，接口的實現被傳遞給它（例如，作爲聚合根上的方法的參數），然後模型決定是否/何時調用該接口上的方法。

實體和值對象對域服務的接口是否具有編譯時間依賴性？它們（域服務的實體，值對象和接口）是否位於域模型的同一層？

是的，是的。例如，這裏的運輸應用的an online sample從第7章

public interface RoutingService { 
    List<Itinerary> fetchRoutesForSpecification(RouteSpecification routeSpecification); 
} 

現在，這個特殊的示範情況，以保持域名服務在不同的命名空間比模型，並使用application service to bridge the two。

return routingService.fetchRoutesForSpecification(cargo.routeSpecification()); 

但它也同樣正確，使模型

return cargo.fetchRoutes(routingService); 

查詢給你一點發揮的餘地責任的一部分，因爲你不必擔心允許該模式保護自己的不變性。隨着命令，後一種方法提供了更好的封裝

order.updateSalesTax(taxCalculatorService); 

Answer 2

服務是根據DDD領域模型的一部分嗎？

它是域圖層的一部分。域服務封裝了無法自然建模爲值對象或實體的域邏輯。

在洋蔥架構中，所有依賴都面向內部。值對象和實體不應該對域服務有任何依賴關係。域服務取決於實體和值對象。該體系結構的核心是域層（值+實體+服務）。這是DDD，它是業務/問題域的抽象視圖。這一層不依賴於任何數據庫，Web服務調用，smtp和其他基礎設施相關服務。

上面的一層是依賴於域層的應用層。應用程序層由包含應用程序邏輯的應用程序服務組成，以編排業務用例。

下一層是基礎結構層，它可以負責存儲信息，日誌記錄，安全性，通知和與其他有界上下文的集成的技術實現。該層還使應用程序層能夠通過Web服務或消息端點來使用。

爲了避免這些層之間的緊密耦合，較高層必須適應較低層的消息類型。在這些層之間，您可以使用數據傳輸對象（DTO），因此您不會跨域傳遞域對象（實體）。另外爲了避免與特定技術（例如數據庫）的緊密耦合，層通過接口進行通信。