我们应该在 DDD 中使用“按功能打包”结构吗？

Question

在做了一些研究之后，我确认folder-by-feature 结构在大多数情况下优于folder-by-layer 结构。要获得一些论点，我们可以阅读以下文章甚至this answer。

Package by features, not layers
Feature folders vs Tech folders
Package by feature, not layer
Package by Layer for Spring Projects Is Obsolete

但是，我发现的所有 DDD 项目示例都是使用 逐层打包 制作的，大部分时间都遵循以下结构：

├── 应用
├── 配置
├── 域名
├── 基础设施
└── 接口

所以我的问题是：为什么 DDD 社区不遵循 package-by-feature，即使它在大多数情况下明显优越？

我们应该在 DDD 中使用 package-by-feature 吗？如果有，该怎么做？

我提到我不是在谈论关于微服务架构的特殊情况，显然逐层封装更多相关的。

Answer 1

我对这个主题的理解和看法如下：

按功能打包是关于垂直切片（根据领域概念构造源代码）而不是水平分层（根据技术概念构造）。

但是说“代替”并不完全正确，因为有时您必须区分这些技术概念。最好是先按功能封装，然后在每个功能内部逐层封装。

在战略性 DDD 中，每个限界上下文 (BC) 都是一个垂直切片（整个应用程序、完整堆栈...具有 UI、应用程序、域模型和基础架构层）。

然后，在 BC 内部，战术 DDD 提倡首先按业务概念打包领域模型代码，然后再按技术概念（战术模式）打包。所以你有模块（紧密结合和松散耦合的聚合组），并且在每个聚合内部都有实体、值对象、工厂、存储库。其他层（UI、应用程序、基础设施）也可以由模块构成。

因此，作为总结，DDD 确实遵循混合方法：

• 按不同粒度级别的业务概念打包：BC、模块、聚合。

• 在 BC 中逐层打包：UI、应用程序、域、基础设施。

PD：这个主题（源代码结构）在 Vaughn Vernon 的书“实施 DDD”的第 9 章（模块）中进行了解释。

Answer 2

DDD 是关于域的，因此将所有内容分组到域文件夹中。但在非常高层保留 4 个六边形架构层。这可能是为了简单起见的包或具有严格相互依赖关系的最佳独立模块（如在 Android Instant Apps 中）。

src/main/java
├── UserInterface
│   ├── OneUseCase.java
│   ├── AnotherUseCase.java
│   └── YetAnotherUseCase.java
├── Application
│   ├── SubDomain1
│   │   └── ... (java files)
│   └── SubDomain2
│       └── ... (java files)
├── Domain
│   ├── SubDomain1
│   │   └── ... (java files)
│   └── SubDomain2
│       └── ... (java files)
└── Infrastructure
    ├── SubDomain1
    │   └── technology1 (java files)
    │   └── technology2. (java files)
    └── SubDomain2
        └── technology1 (java files)
        └── technology2. (java files)

这是一个a good article 清晰的解释。

Answer 3

为什么 DDD 社区不按功能进行包

我想你会发现好的项目确实会按功能打包。

在示例中，您可能会发现它没有被遵循。慷慨的解释是，作者试图让人们更容易识别关注点的分离和依赖箭头的方向。

不够慷慨？作者没有注意，或者不知道更好。

我们应该在 DDD 中使用 package-by-feature 吗？如果有，该怎么做？

是的，如果您不执行 DDD，您将按功能打包的方式几乎相同。它们是正交关注点。