Question

经过研究，我确认在大多数情况下，按功能文件夹的结构要优于按功能文件夹的结构。要获取一些论点，我们可以阅读以下文章，甚至甚至是this answer。

但是，我发现的所有DDD项目示例都是使用逐层打包制作的，大多数情况下都是这样的结构：

├──应用程序
├──配置
├──域
├──基础设施
──接口

所以我的问题是：为什么DDD社区不遵循按功能打包，即使在大多数情况下它显然更胜一筹？

我们应该在DDD中使用按功能打包吗？如果是这样，该怎么做？

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

Answer 1

为什么DDD社区不按功能打包

我认为您会发现好的项目确实是按功能打包的。

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

慷慨地减少？作者没有注意，还是不了解。

我们应该对DDD使用按功能打包吗？如果是这样，该怎么做？

是的，如果您不进行DDD，您几乎可以按功能逐个打包。它们是正交的问题。

Answer 2

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

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

但是说“代替”并不是完全正确的，因为有时您必须区分这些技术概念。最好先说按要素打包，然后再在每个要素内逐层打包。

在战略DDD中，每个绑定上下文（BC）都是一个垂直切片（整个应用程序，完整的堆栈...以及UI，应用程序，域模型和基础结构层）。

然后，在BC内部，战术DDD促进按业务概念，然后按技术概念（战术模式）打包域模型代码。因此，您拥有模块（紧密结合且松散耦合的聚合组），并且在每个聚合内，您都有实体，值对象，工厂，存储库。其他层（UI，应用程序，下文）也可以由模块构成。

因此，作为摘要，DDD确实采用了混合方法：

PD：沃恩·弗农（Vaughn Vernon）的书“实施DDD”的第9章（模块）对此主题（源代码结构）进行了解释。

Answer 3

将您的项目分成4层（没有相互依赖性的Java Project模块）。只有基础架构才能访问域和接口。应用程序作为切入点。 Google针对Android Instant Apps提出了相同的结构。

#ifdef DEBUG

这是一个a good article，简明的解释。