在做了一些研究之后，我得到了确认，在大多数情况下，逐个文件的结构优于逐层结构。为了得到一些论点，我们可以阅读以下文章甚至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社区不遵循逐个功能，即使它在大多数情况下显然更优越？
我们应该使用DDD的逐个功能吗？如果是这样，怎么办？
我提到我不是在谈论微服务架构的特殊情况，其中显然逐层更具相关性。
为什么DDD社区不遵循逐个功能
我想你会发现好的项目确实遵循逐个功能。
在示例中，您可能会发现它没有被遵循。慷慨的解释是作者试图让人们更容易认识到关注点的分离和依赖性箭头的方向。
不那么慷慨？作者没有注意，或者不知道更好。
我们应该使用DDD的逐个功能吗？如果是这样，怎么办？
是的，如果您没有使用DDD，那么就像逐个功能一样。它们是正交问题。
我对这个主题的理解和看法如下：
逐个功能包括垂直切片（根据域概念构造源代码）而不是水平分层（根据技术概念构造）。
但是说“而不是”并不完全正确，因为有一个时刻你必须区分这些技术概念。最好先说出逐个功能，然后在每个功能中逐个包装。
在战略DDD中，每个有界上下文（BC）是一个垂直切片（整个应用程序，完整堆栈......具有UI，应用程序，域模型和基础结构层）。
然后，在BC内部，战术DDD首先通过业务概念促进打包域模型代码，然后通过技术概念（战术模式）。所以你有模块（紧密内聚和松散耦合的聚合组），并且在每个聚合内部都有实体，值对象，工厂，存储库。其他层（UI，应用程序，infra）也可以由模块构建。
因此，作为摘要DDD确实遵循混合方法：
PD：这个主题（源代码结构）在Vaughn Vernon的书“实现DDD”的第9章（模块）中进行了解释。