Domain Driven Design - where does data parsing belong

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:

1. Directory watcher service sees a new appliance file has been added
2. 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 submittin开发者_运维技巧g 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.

According SRP (Single Responsibility Principle), you should keep your consideration. Directory Watcher service should do what it does best - watch for new files in a directory and pass them to another service, ie Appliance Service which converts them into data transfer objects. Now you can use your web services to submit those data transfer objects to the Application.

I would make an interface for Appliance Service, with at least one method called Convert(). Appliance Parsing Service class can implement the interface. Let's say later you have a different source (SQL) for appliances. You can write another class Appliance SQL Service that implements Appliance Service.

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.