From cb7408195b1d0935a90e083238f026c9f2bd2c66 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Halil=20=C4=B0brahim=20Kalkan?= Date: Sun, 29 Nov 2020 20:34:09 +0300 Subject: [PATCH] Update Domain-Driven-Design-Implementation-Guide.md --- docs/en/Domain-Driven-Design-Implementation-Guide.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/en/Domain-Driven-Design-Implementation-Guide.md b/docs/en/Domain-Driven-Design-Implementation-Guide.md index 7c0999e975..0666b18e07 100644 --- a/docs/en/Domain-Driven-Design-Implementation-Guide.md +++ b/docs/en/Domain-Driven-Design-Implementation-Guide.md @@ -1104,6 +1104,8 @@ The only problem of this design is that `Issue.AssignedUserId` is now open to se While there is a tradeoff between two approaches, we prefer to create Domain Services when the business logic requires to work with external services. +> If you don't have a good reason, we think **there is no need to create interfaces** (like `IIssueManager` for the `IssueManager`) for Domain Services. + ### Application Services An [Application Service](Application-Services.md) is a stateless service that implements **use cases** of the application. An application service typically **gets and returns DTOs**. It is used by the Presentation Layer. It **uses and coordinates the domain objects** (entities, repositories, etc.) to implement use cases.