laravel 领域驱动设计（DDD）中服务库应该放在哪里

Question

DDD

是

Domain Driven Design

的简写

问题1：

以前，当使用原始的 Laravel 模式时.. 使用服务库，如 FileOperation、Curl、调用过程，如“ps、python 脚本”等。 文件默认放置在

app/Services

目录..

问题2：

我还有自定义存根生成器。使用 php artisan make:anything 等命令生成存根。 自从研究了一些文章并发现

app/Console/Kernel.php

已移至

app/Infrastructure/Laravel/Kernel/Console.php

使用 DDD 后。我不知道把这些文件放在哪里。 谷歌搜索了几天，只发现了一堆与 DDD 无关的内容

我应该将问题 1 所解释的服务放在哪里？ 最好戴上：

• app/Infrastructure/Service

• app/Infrastructure/<service name dir>/*.php

• app/Application

或者让它保持开启状态

app/Services

那些控制台生成器要放在哪里？ 是否应该继续

app/Console/*.php

或者放在：

• app/Interface/Console/*.php

• app/Infrastructure/Console/*.php

或者有什么建议

Answer 1

您引用的文章将 DDD 与 4 层架构混淆了。

领域驱动开发

DDD 是 Eric Evans 在其 2003 年出版的著作《领域驱动设计：解决软件核心的复杂性》中提出的概念。 DDD 的原理是创建一个单独的代码单元，称为“域层”，其中包含业务规则验证所需的所有代码。该代码单元必须设计为跨多个应用程序工作，并且应该独立于基础设施。 DDD可以在不同的应用架构中使用：虽然代码单元被称为业务层，但您可以在非分层架构应用程序中使用DDD。尽管 DDD 指出依赖于基础设施的概念不属于领域层，但它对非领域单元的结构没有任何要求。

就 DDD 本身而言，FileOperation、Curl...走“领域层之外”。 4层架构

4层架构是一种经典的n层架构，由4个独立层组成：

用户界面/表示层

领域/业务层

• 基础设施/持久化/数据层
• 应用层
哪一层可以引用哪一层是有微妙之处的，但是使用 DDD 进行 4 层通常意味着领域层不允许引用其他层的代码。这与之前的 n 层实践有所不同，之前的 n 层实践是业务层引用数据层。这使得业务规则代码单元依赖于基础设施，因此不能转移到其他应用程序。改变这种做法是 DDD 的主要目的。
传统上，n 层架构具有单个整体基础设施层。通常，基础设施仅限于单个 RDBMS，您将在基础设施层中实现对象到 SQL 操作，充当域模型和数据库之间的中介。一些应用程序具有更复杂的基础设施和多个数据源，一些工程师开始推广不太线性的架构模式，例如 2005 年 Alistair Cockburn 的

六边形架构

，后来由 Jeffrey Palermo 于 2008 年丰富为 Onion 架构，然后是 Clean Robert C. Martin 在 2012 年提出的架构。

结论 我将 h1b1t 的结构视为纯粹的建议，我没有足够的专业知识来批评他们建议如何组织

app/Infrastructure/Laravel

文件夹。然而，我的理解是，该文件夹包含来自框架的所有依赖于基础设施的代码。因此，诸如您的服务之类的代码不应该出现在那里。

如果在访问基础设施（数据库、外部 API 等）时使用您的服务，则它应该位于

app/Infrastructure

目录中，但位于 app/Infrastructure/Laravel 之外。如何构建基础设施层取决于您的实际基础设施，并且每个外部服务应该有一个目录。如果调用不同数据源时使用此代码，那么您可以有一些

app/Infrastructure/Commons

目录。

如果这些服务独立于基础设施，则它们位于

app/Application

中。例如，控制台生成器不依赖于基础设施，应该放入

app/Application/Console