域驱动设计 - 数据解析属于何处

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 SQL Service实现Appliance Service.