在我正在开发的这个应用程序中，域名围绕着电器。该实体有几个专门版本。可以将设备提交给应用程序，这可以通过使用数据传输对象的Web服务进行。
虽然这很有效，但我现在正在考虑从几种基于文本的文件格式导入设备。考虑这个工作流程：
现在，应用程序服务可以使用具有以下名称和签名的方法：ApplianceService.Register(string fileContents)。我认为目录观察者服务将使用此服务方法并将其传递给文件的全部内容。然后，应用程序服务将协调解析。解析文件的内容并将其转换为完整的设备实体涉及几个步骤。现在，我的问题是：
问题：这是正确的，还是解析逻辑应该存在于目录观察服务中？每种类型的文件格式都是类域的一部分，但话说再说不是。在将文件从任一格式解析为实体之后，实体将永远不会知道它曾使用该格式表示过。如果解析逻辑应该存在于观察者服务中，我会将新设备作为数据传输对象传递给注册服务。
我想我关心的是设备在进入我的应用程序之前应该如何表示（使用应用程序层作为入口点）。从Web服务提交设备时，我会传递一系列设备数据传输对象。这与获取可能格式奇怪的文件并将其解析为数据传输对象不同，因为从Web服务请求到数据传输对象的映射非常简单，而且并不复杂。
对此非常欢迎。
答案 0 :(得分：1)
根据SRP（单一责任原则），您应该继续考虑。 Directory Watcher service应该做它最擅长的事情 - 监视目录中的新文件并将它们传递给另一个服务，即Appliance Service将它们转换为数据传输对象。现在，您可以使用web services将这些数据传输对象提交给应用程序。
我会为Appliance Service创建一个界面，至少有一个名为Convert()的方法。 Appliance Parsing Service类可以实现该接口。让我们稍后说你有不同的设备来源（SQL）。您可以编写另一个实现Appliance SQL Service的类Appliance Service。
答案 1 :(得分：1)
我会说ApplicationService是解析逻辑的正确位置，认为把它放在DirectoryWatcher服务中并不是一件坏事。
我对该陈述的推理来自单一责任原则的观点：DirectoryWatcher特别不应负责管理所有各种输入文件格式。它应该抓住它收到的东西并将它传递到正确的地方（已经是一个非常复杂的责任）。
我的头转了一下（可能与你自己一样？）是因为它不是ApplicationService的责任，它协调你的各种域实体。但是，我觉得ApplicationService是利用某种Builder模式的正确位置，抽象出每个解析每个文件的方法的细节，同时也在Domain中创建一个清晰的位置来协调这个解析。
每个文件格式是否属于域的一部分。我会说它们是 - 你可以想象它们都被表达为无处不在的语言的一部分，让各种领域的专家讨论x文件格式或y文件格式的怪癖和表达的数据。那种解析和映射是非常一流的域逻辑。
原始设计的另一个好处是我认为它可以简化添加新输入文件源和格式以及修改现有文件。您已将文件源与特定格式分离，并创建了一个很好的接口点（ApplicationService），您的新文件提供程序将访问核心应用程序。