Domain driven design DDD-如何在应用层重用代码？

如何在没有映射的情况下重用应用层中的代码

让我们使用AddOrder（OrderDto）方法创建一个应用程序服务OrderService。 RESTAPI使用该方法。控制器方法调用OrderService.AddOrder（OrderDto），并将OrderDto参数映射到Order实体。然后将订单实体添加到存储库中。映射在那里完成，因为OrderService和AddOrder是一个应用程序接口

重用代码并调用OrderService.AddOrder（orderDto）会很好，不仅可以从控制器调用，还可以从OrderService中的另一个方法调用，甚至可以从另一个应用程序服务调用

然而，在调用另一个应用程序方法，然后将结果从DTO映射回实体之前，它始终需要在应用程序服务方法中从实体映射到DTO

=>同一层中的无用映射。随着系统变得越来越大，它最终会从DTO映射到任何地方。糟糕

最好避免内部映射，而只在应用程序界面的顶部进行映射。 我们可以在params:OrderDomainService.AddOrder（order）中编写一个接受域模型（实体）而不是DTO的服务

这就解决了“映射问题”。域服务可以在没有映射的情况下相互调用，应用程序服务也可以调用域服务。但是，这意味着域服务必须使用基础架构层的存储库来加载数据，因为我们将代码从应用程序服务方法移动到了域服务方法。这将创建从域层到基础结构层的依赖关系

=>错误的依赖关系。基础架构应该依赖于域，而不是依赖于域的内部结构

如何解决这个问题

应用程序服务不应包含具有域模型类型参数的方法。 域服务无法使用存储库

那么，在哪里编写可重用代码呢

或者我错了，域服务可以使用存储库。通过域层中的接口，它不会直接依赖于基础结构层。

---

然而，它最终将由一个控制器方法调用一个应用程序服务方法调用一个域服务方法。

我认为在重用逻辑方面，您朝着域服务的方向发展是正确的。应用程序服务适合编排特定的用例，并且只按正确的顺序调用不同的操作。域逻辑应始终位于域层中

关于基础设施依赖性：对于在DDD（或clean架构）中使用存储库，存储库接口应位于域层，而这些接口的具体实现位于基础设施层

应用层和域层都应该依赖于接口，而不是基础结构层

域服务无法使用存储库

因此，它可以通过依赖于存储库接口来使用存储库，而具体的基础结构存储库是在依赖项注入之后在运行时注入的

然而，它最终将由一个控制器方法调用一个应用程序服务方法调用一个域服务方法

---

如果应用程序服务没有正当理由，因为不需要真正的编排，那么在让控制器直接调用域类时，至少不要破坏任何依赖性规则，例如，如果用例太简单，不需要API层（这里是控制器）和域层之间的抽象。但我通常更喜欢使用应用程序服务，因为它们使域层独立于此外层，并允许域层和API层彼此独立发展。

我认为在重用逻辑方面，您朝着域服务的方向发展是正确的。应用程序服务适合编排特定的用例，并且只按正确的顺序调用不同的操作。域逻辑应始终位于域层中

关于基础设施依赖性：对于在DDD（或clean架构）中使用存储库，存储库接口应位于域层，而这些接口的具体实现位于基础设施层

应用层和域层都应该依赖于接口，而不是基础结构层

域服务无法使用存储库

因此，它可以通过依赖于存储库接口来使用存储库，而具体的基础结构存储库是在依赖项注入之后在运行时注入的

然而，它最终将由一个控制器方法调用一个应用程序服务方法调用一个域服务方法

---

如果应用程序服务没有正当理由，因为不需要真正的编排，那么在让控制器直接调用域类时，至少不要破坏任何依赖性规则，例如，如果用例太简单，不需要API层（这里是控制器）和域层之间的抽象。但我通常更喜欢使用应用程序服务，因为它们使域层独立于此外层，并允许域层和API层彼此独立发展。

如果域服务可以使用基础结构代码（通过域层中的接口），那么它可以使用存储库，然后，它可以用作编排器，而不是应用程序服务方法。它可以使应用程序主要由域服务中的代码组成，如果域服务方法应该在应用程序外公开，则可以由包含映射代码的应用程序服务方法“包装”它。从实用的角度来看，这将是非常好的，但是编排逻辑将在域s中是正确的吗