领域驱动设计——数据解析属于哪里
在我正在开发的这个应用程序中，该领域围绕着电器。该实体有几个专门的版本。设备可以提交给应用程序，这通过使用数据传输对象的 Web 服务来实现。
虽然这很有效，但我现在也在考虑从几种基于文本的文件格式导入设备。考虑以下工作流程：
- 目录观察程序服务看到已添加新的设备文件
- 该服务使用我的应用程序中的应用程序服务来提交文件描述的设备
现在，应用程序服务可以具有具有以下名称和签名的方法： ApplianceService.Register（字符串文件内容）。我认为目录观察程序服务将使用此服务方法并向其传递文件的全部内容。然后应用程序服务将协调解析。解析文件内容并将其转换为完整的设备实体涉及几个步骤。现在，我的问题是：
问题：这是正确的吗？还是解析逻辑应该存在于目录观察程序服务中？每种类型的文件格式都是域的一部分，但事实并非如此。将文件从任一格式解析为实体后，该实体将永远不会知道它曾经使用该格式表示。如果解析逻辑应该存在于观察者服务中，我会将新设备作为数据传输对象传递给注册服务。
我想我关心的是设备在进入我的应用程序之前应该如何表示（使用应用程序层作为入口点）。从 Web 服务提交设备时，我传递了一系列设备数据传输对象。这与采用可能奇怪的格式的文件并将其解析为数据传输对象不同，因为从 Web 服务请求到数据传输对象的映射非常简单，而且并不复杂。
对此有任何想法都非常受欢迎。
In this application I'm developing, the domain revolves around, say, electrical appliances. There are several specialized versions of this entity. Appliances can be submitted to the application, and this happens from web services using data transfer objects.
While this is working great, I am now looking at importing appliances from several text-based file formats as well. Consider this workflow:
- Directory watcher service sees a new appliance file has been added
- The service uses an application service from my application to submit the appliances described by the file
Now, the application service could have a method with the following name and signature: ApplianceService.Register(string fileContents). I'm thinking the directory watcher service will use this service method and pass it the entire contents of the file. The application service will then coordinate the parsing. Parsing the contents of the file and transforming it into complete appliances entities involves several steps. Now, my question is:
Question: Is this correct, or should the parsing logic live within the directory watcher service? Each type of file format is kind of a part of the domain, but then again, it's not. After the files are parsed into entities from either format, the entity will never know that it once was represented using that format. If the parsing logic should live within the watcher service, I would pass the new appliances to the registration service as data transfer objects.
I guess what I'm concerned about is how an appliance should be represented before it enters my application (using the application layer as point of entry). When submitting appliances from web services, I pass a sequence of appliance data transfer objects. This is different from taking a potentially oddly formatted file and parsing that into a data transfer object, since the mapping from the web service request to data transfer object is pretty straight forward, and not that complex.
Any thoughts on this are very much welcome.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
根据SRP（单一责任原则），您应该慎重考虑。
Directory Watcher 服务应该做它最擅长的事情 - 监视目录中的新文件并将它们传递给另一个服务，即Appliance Service将它们转换为数据传输对象。现在，您可以使用Web 服务将这些数据传输对象提交到应用程序。我将为
Appliance Service创建一个接口，其中至少有一个名为Convert()的方法。Appliance Parsing Service类可以实现该接口。假设稍后您有不同的设备源 (SQL)。您可以编写另一个实现Appliance Service的类Appliance SQL Service。According SRP (Single Responsibility Principle), you should keep your consideration.
Directory Watcher serviceshould do what it does best - watch for new files in a directory and pass them to another service, ieAppliance Servicewhich converts them into data transfer objects. Now you can use yourweb servicesto submit those data transfer objects to the Application.I would make an interface for
Appliance Service, with at least one method calledConvert().Appliance Parsing Serviceclass can implement the interface. Let's say later you have a different source (SQL) for appliances. You can write another classAppliance SQL Servicethat implementsAppliance Service.我想说 ApplicationService 是解析逻辑的正确位置，认为将其放在 DirectoryWatcher 服务中并不是完全不合适。
我对该声明的推理来自单一责任原则的观点：DirectoryWatcher 特别不应该负责管理所有各种输入文件格式。它应该只获取收到的内容并将其传递到正确的位置（这已经是一项非常复杂的责任）。
我的想法有点转变（这可能和你一样？）是协调您的各个域实体的 ApplicationService 并不是真正的责任。但是，我认为 ApplicationService 是利用某种构建器模式的正确位置，它抽象了解析每个文件的每种方法的细节，同时也在域中创建了一个协调解析的清晰位置。
至于每种文件格式是否属于域。我想说的是——你可以想象它们都被表达为通用语言的一部分，让各种领域专家谈论 x 文件格式或 y 文件格式的怪癖以及所表达的数据。这种解析和映射是非常一流的领域逻辑。
原始设计的另一个好处是，我认为它将简化添加新的输入文件源和格式以及修改现有文件源和格式的过程。您已将文件源与特定格式解耦，并创建了一个很好的接口点（ApplicationService），您的新文件提供程序可以在其中访问核心应用程序。
I'd say that the ApplicationService is the right place for the parsing logic, thought it would not be an entirely bad fit to put it in the DirectoryWatcher service.
My reasoning for that statement comes from a Single Responsibility Principle point of view: The DirectoryWatcher in particular should not be responsible for managing all the various input file formats. It should just grab what it receives and pass it on to the right place (already a very involved responsibility).
Where my head got a little turned around (which is maybe the same as yourself?) was that it isn't really the responsibility of the ApplicationService which coordinates your various domain entities. However, I feel that the ApplicationService is the right place to leverage some sort of Builder pattern, abstracting away the details of each method of parsing each file but also creating a clear place in the Domain where this parsing is coordinated.
As for each file format being part of the domain or not. I'd say that they are - you can imagine them all being expressed as part of the ubiquitous language, having various domain experts talking about the quirks of x file format or y file format and the data expressed. That sort of parsing and mapping is very much first class domain logic.
Another nice side of your original design is I think it would simplify adding in new input file sources and formats and modifying existing ones. You have decoupled the file source from the specific format, and created a nice interface point (the ApplicationService) where your new file providers access the core applications.