领域驱动设计 - 数据解析属于哪里

Question

在我正在开发的这个应用程序中，领域围绕着，比如说，电器。这个实体有几个专门的版本。设备可以提交给应用程序，这发生在使用数据传输对象的 Web 服务中。

虽然这很好用，但我现在也在考虑从几种基于文本的文件格式导入设备。考虑一下这个工作流程：

1. 目录观察服务发现新的设备文件已添加
2. 该服务使用我的应用程序中的应用程序服务来提交文件描述的设备

现在，应用程序服务可以有一个具有以下名称和签名的方法：ApplianceService.Register(string fileContents)。我认为目录观察服务将使用此服务方法并将文件的全部内容传递给它。然后应用程序服务将协调解析。解析文件的内容并将其转换为完整的设备实体涉及几个步骤。现在，我的问题是：

问题：这是正确的，还是解析逻辑应该存在于目录观察服务中？每种类型的文件格式都是一种域的一部分，但话又说回来，它不是。在将文件从任一格式解析为实体后，实体将永远不会知道它曾经使用该格式表示过。如果解析逻辑应该存在于观察者服务中，我会将新设备作为数据传输对象传递给注册服务。

我想我关心的是设备在进入我的应用程序之前应该如何表示（使用应用程序层作为入口点）。从 Web 服务提交设备时，我传递了一系列设备数据传输对象。这与获取可能格式不正确的文件并将其解析为数据传输对象不同，因为从 Web 服务请求到数据传输对象的映射非常简单，而且并不复杂。

非常欢迎对此提出任何想法。

Answer 1

根据 SRP（单一职责原则），您应该保持考虑。 Directory Watcher service 应该做它最擅长的事情 - 监视目录中的新文件并将它们传递给另一个服务，即 Appliance Service 将它们转换为数据传输对象。现在您可以使用您的web services 将这些数据传输对象提交给应用程序。

我会为Appliance Service 制作一个接口，其中至少有一个名为Convert() 的方法。 Appliance Parsing Service 类可以实现接口。假设稍后您有不同的设备源 (SQL)。您可以编写另一个实现Appliance Service 的类Appliance SQL Service。

Answer 2

我会说 ApplicationService 是解析逻辑的正确位置，认为将它放在 DirectoryWatcher 服务中并不是完全不合适的。

我对这种说法的推理来自单一职责原则的观点：DirectoryWatcher 尤其不应该负责管理所有各种输入文件格式。它应该只抓取它收到的内容并将其传递到正确的地方（这已经是一项非常复杂的责任）。

我的头有点转过来（这可能和你自己一样？）是它实际上并不是 ApplicationService 的责任，它协调你的各种域实体。但是，我觉得 ApplicationService 是利用某种 Builder 模式的正确位置，它抽象出解析每个文件的每种方法的细节，但也在域中创建了一个清晰的位置，用于协调该解析。

至于每种文件格式是否属于域的一部分。我会说它们是——你可以想象它们都被表达为无处不在的语言的一部分，让各种领域专家谈论 x 文件格式或 y 文件格式的怪癖和表达的数据。这种解析和映射是非常一流的领域逻辑。

您的原始设计的另一个优点是我认为它可以简化添加新输入文件源和格式以及修改现有文件的过程。您已将文件源与特定格式分离，并创建了一个很好的接口点（ApplicationService），您的新文件提供程序可以在其中访问核心应用程序。