DDD文件夹结构：不同文件夹中的拆分存储库，还是将所有业务规则保留在通用文件夹中？

Question

假设我有一堆用于抽象模块的集成：解析器和订购。

您如何说在DDD的角度组织文件夹结构的更好方法？

ordering/
----abstract.py
parser/
----abstract.py
integration1/
----ordering.py  # depends on ordering.abstract
----parser.py  # depends on parser.abstract
integration2/
----ordering.py  # depends on ordering.abstract
----parser.py  # depends on parser.abstract

或

ordering/
----abstract.py
----integration1.py  # depends on abstract
----integration2.py  # depends on abstract
parser/
----abstract.py
----integration1.py  # depends on abstract
----integration2.py  # depends on abstract

抽象文件处理我的应用程序的业务规则（我们如何验证数据，如何协调请求响应周期等）以及集成文件处理第三方的业务规则（我们如何解释他们发送的数据，我们如何以他们期望的方式准备数据等）。

就像我看到的那样，每个集成充当某种存储库，其核心实现依赖于Abstract.py。

我倾向于使用第一种方法，因为我们明确将这些域分开，但同时所有文件都具有相同的目的。

你的想法是什么？

Answer 1

您在这里有两个问题：在域层中使用抽象并集成外部上下文。

域中的抽象

抽象文件处理我的应用程序的业务规则（我们如何验证数据，如何协调请求响应周期等）

）

仅构成abfictions的域层（或软件包）（即其他语言中的接口，您需要查找它的依赖关系的Python类似物并从不同包装中注入其具体实现是一个很好的做法。这使域层与基础架构无关。有一种建筑模式，促进了这种做法，称为端口和适配器架构。您的第一个建议在某种程度上暗示了这种模式。

此外，在DDD中，大多数业务规则都由主要结构执行：汇总根（域中最杰出的实体）， Entities 和 value对象。所有这些都以具体类型的形式实现，无需将它们抽象。 存储库，域服务等依赖项被抽象。

这里遵循一个潜在的目录方案，当然可以进行修改，尊重我提到的惯例：

.
../domain
..../model
....../entity1
....../value object 1
....../entity2
..../services
....../service1 (interface)
....../service2 (interface)
..../repositories
....../repository1 (interface)
....../repository2 (interface)
../port
..../adapter
....../services
......../service1 (concrete)
......../service2 (concrete)
....../repositories
......../repository1 (concrete)
......../repository2 (concrete)

整合外部环境

...，集成文件处理第三方的业务规则（我们如何解释他们发送的数据，我们如何以他们期望的方式准备数据等）

）

集成外部上下文（上下文映射在DDD术语中）本身是一个挑战。 DDD的战略性涉及此问题，并建议根据它们之间关系的性质整合上下文的几种选项。所有选项都在努力确保与外部上下文的通信通过一些翻译过程；外部上下文必须不要浸润。

我看到的方式，每个集成都充当某种存储库，其核心实现依赖于Abstract.py。

在DDD中，存储库旨在检索和修改聚合根。 您的翻译的某些确实非常适合存储库模式，您可以在其之后对其进行建模。但是，其中一些可能更好地适合域服务。就像任何其他存储库和域服务一样，您可以将集成的抽象放在域软件包中及其实现。