领域驱动设计（DDD）：文件结构

项目当前文件结构

领域

DDD（领域驱动设计）

模块

共享

基础设施层 vs 领域层

使用 DDD 的项目文件结构

最后的考虑

保持联系

项目当前文件结构

src文件夹
 - config文件夹
 -数据库文件夹
 -错误文件夹
 -中间件文件夹
 -模型文件夹
 -存储库文件夹
 -路由文件夹
 -服务文件夹

src文件夹应该包含我们的应用程序模块。其中的所有内容都会直接影响应用程序的功能。

我们目前按文件类型分离我们的应用程序。因此，服务类型的文件存储在 services 文件夹中。

问题在于：如果我们有 10 个模型，那么大约会有 40-50 个服务。这么多文件不处理同一个模块，或者换句话说，不处理同一个领域，会造成混乱。

领域

是涉及特定文件或模块的知识领域。一组业务规则。

因此，根据文件类型来划分文件来构建项目结构并不总是好的。

构建项目结构的一个好方法是使用模块根据事物的领域进行隔离。

因此，与用户相关的服务（例如验证用户服务，创建预约服务，创建用户服务，更新用户头像服务）都应属于用户域。

将会有一个预约域，它只负责处理与预约相关的业务逻辑，无论是创建预约、列出预约、检查可用的预约还是取消预约。

DDD（领域驱动设计）

Scrum是一种敏捷方法，允许团队以敏捷的方式组织和执行他们的任务。

但Scrum并非对所有团队和项目都适用相同的工作方式，我们会根据自身情况，以更合理的方式来实现这些想法和概念。DDD的工作方式也类似，有些概念只适用于企业级应用程序（非常大型的应用程序）。

模块

我们的应用程序中有哪些模块（知识领域）？用户域和预约域。
我们必须创建一个模块 文件夹来容纳我们的模块，并在其中创建用户和预约子 文件夹。

我们可以在 modules/users 文件夹中存储什么？

• DTO
• 实体/模型
• 存储库（包括我们为 TDD 提供的伪/模拟实现）、服务
• 特定于用户的提供程序（对用户密码进行哈希处理的哈希提供程序）
• 特定于用户的基础设施（我们将在下面看到基础设施层的含义）。

共享

所有模块或多个模块之间共享的逻辑文件应保存在模块文件夹之外的共享文件夹中。

我们可以在共享文件夹中存储什么？

• 错误
• 共享数据库文件（连接和迁移）
• 共享路线
• 共享中间件
• 共享提供商（存储提供商、电子邮件提供商）。

基础设施层 vs 领域层

领域：涉及特定模块的知识领域。一组业务规则。它负责应用程序如何工作。

基础设施层：指最初由领域实体（内存）保存的数据如何持久化到数据库或其他持久化存储中。基础设施层不得“污染”领域模型层。 
注意：它包含我们应用程序的技术决策。

在创建eBarber时，与理发师或用户会面将有助于您更好地确定领域/业务逻辑。但是理发师缺乏专业知识来告诉您应该使用哪些工具：是应该使用 ORM 还是查询生成器。

CTO 和/或高级工程师决定与基础设施层相关的事务。

用户域知道用户注册后应该收到邮件，但不知道发送邮件的工具是什么。这就是基础设施层的作用。

阅读：Microsoft 和面向 DDD 的微服务

基础设施

为了容纳基础设施层，我们可以创建多个infra文件夹。我们可以在共享文件夹内以及每个模块（用户和预约）内分别创建一个infra文件夹。

我们可以在infra文件夹中创建一个数据库文件夹，用于处理与数据库相关的内容。我们应该给它起一个特定的名称，因为我们的项目使用 TypeORM，所以我们应该将数据库文件夹命名为typeorm。

我们还可以在infra文件夹中创建一个http文件夹，用于处理与 http 请求和响应相关的内容，例如server.ts、路由和中间件。注意：再次强调，我们应该给它一个特定的名称。如果我们使用其他类型的协议，例如gRPC，我们就会给它另一个名称。

附加说明

1. Infra 将存储与特定包或库相关的所有信息。例如：TypeORM。
2. 错误可能会被共享，但它们不是底层的一部分。
3. 最好将可能发生变化的内容包含在 infra 文件夹中。
   • 示例 1：快速路由和中间件。
   • 示例 2：想象一下，如果我们需要将通信协议从 HTTP 更改为 gRPC。

使用 DDD 的项目文件结构

最后的考虑

领域驱动设计的主要优势在于能够创建具有明确定义、组件之间具有清晰契约的代码。这使我们能够更好地定义组件的职责，使更新或替换组件变得更加容易，同时减少对整个系统的影响。

DDD 的主要缺点是它假设你对想要实现的解决方案有一个相当清晰的认识，但事实并非总是如此。解决这个问题的一个方法是创建一个小型原型，并对其进行多次迭代，直到你对它有了足够的理解，从而得出合理的设计。这可能会延迟项目的启动，但可能会产生更易于维护的解决方案。

这篇文章仅触及冰山一角，我鼓励您阅读更多有关 DDD 的内容，包括有关应用层的内容。

保持联系

通过我的社交媒体联系我。我们可以在LinkedIn或GitHub上讨论 DDD、TDD 和最佳实践。

与我们分享您如何决定项目文件结构。