DDD架构文件夹结构选型：按集成拆分还是按领域模块存放仓储实现？

问题背景 #

现有多套第三方集成实现，依赖parser、ordering两个核心抽象模块，需要从两种常见目录组织方式中选择符合DDD最佳实践的方案。
两种备选结构如下：

结构1：按集成维度拆分 #

ordering/
----abstract.py
parser/
----abstract.py
integration1/
----ordering.py  # 依赖 ordering.abstract
----parser.py  # 依赖 parser.abstract
integration2/
----ordering.py  # 依赖 ordering.abstract
----parser.py  # 依赖 parser.abstract

结构2：按核心领域模块维度拆分 #

ordering/
----abstract.py
----integration1.py  # 依赖同目录下的abstract抽象
----integration2.py  # 依赖同目录下的abstract抽象
parser/
----abstract.py
----integration1.py  # 依赖同目录下的abstract抽象
----integration2.py  # 依赖同目录下的abstract抽象

前提约定 #

• abstract.py承载核心领域业务规则：包含数据校验、请求-响应周期编排等核心逻辑，属于领域层对外暴露的稳定抽象契约
• 各integration文件承载第三方适配逻辑：包含第三方传入数据解析、符合第三方要求的请求组装等逻辑，属于防腐层/仓储的基础设施实现

选型结论 #

绝大多数场景下优先选择结构2，仅当单套集成的跨模块逻辑强绑定时才考虑结构1

核心理由 #

你倾向结构1的出发点是“清晰划分领域边界”，这里存在一个常见认知偏差：DDD的领域边界是围绕核心业务能力划分的，第三方集成是核心能力的落地实现细节，本身不属于领域边界范畴。

• 结构2完全符合DDD分层的依赖倒置原则：abstract.py定义的核心规则是稳定的领域内核，所有集成适配作为基础设施层实现，向内依赖内核契约。同领域的所有逻辑（抽象契约+全部实现）内聚在同一目录下，开发者要了解ordering/parser模块的全量逻辑，不需要跨多个分散的集成目录查找，领域边界不会被第三方接入方的维度打散。
• 结构1的维护成本会随集成数量线性上升：后续如果给ordering抽象新增接口方法，需要遍历所有integration目录找到对应实现逐一修改；且同一集成目录下的parser、ordering代码因为物理位置相邻，很容易出现绕过领域抽象的直接调用，逐步腐化核心领域的隔离性。
• 结构2对架构演进更友好：新增第三方集成时，只需要在两个核心模块下分别新增一个适配文件即可；下线旧集成时也只需要删除两个对应文件，不需要频繁新增/删除整级目录。如果后续需要做集成插件化加载，也可以直接按文件名匹配对应实现，不需要做跨目录的代码分拣。

例外适用场景 #

只有当单套集成的parser和ordering逻辑存在强绑定、完全无法跨集成复用时（比如某第三方的协议完全自定义，解析出的数据结构只能给同家的排序逻辑使用，和核心领域的通用契约差异极大），才适合用结构1。但出现这种情况往往意味着核心抽象设计没有抽离到位，应该优先调整抽象层的契约定义，而不是靠目录结构妥协。 #

内容的提问来源于stack exchange，提问作者Murilo Sitonio