Домен-управляемый дизайн - где находится анализ данных

Question

В этом приложении, которое я разрабатываю, домен вращается вокруг, скажем, электрических приборов .Существует несколько специализированных версий этой сущности.Устройства могут быть отправлены в приложение, и это происходит из веб-сервисов, использующих объекты передачи данных.

Хотя это работает отлично, сейчас я также рассматриваю импорт устройств из нескольких текстовых форматов файлов.Рассмотрим этот рабочий процесс:

1. Служба просмотра каталогов видит, что был добавлен новый файл устройства
2. Служба использует службу приложения из моего приложения для отправки устройств, описанных файлом

Теперь у службы приложения может быть метод со следующим именем и подписью: ApplianceService.Register(string fileContents).Я думаю, что служба наблюдения за каталогами будет использовать этот метод службы и передать ему все содержимое файла.Служба приложений будет координировать разбор.Разбор содержимого файла и его преобразование в целые объекты устройств включает в себя несколько этапов.Теперь мой вопрос:

Вопрос: Это правильно, или логика синтаксического анализа должна существовать в службе наблюдателя каталога?Каждый тип формата файла является своего рода частью домена, но опять же, это не так.После разбора файлов на сущности из любого формата сущность никогда не узнает, что когда-то она была представлена ​​в этом формате.Если логика синтаксического анализа должна существовать в службе наблюдателя, я передам новые устройства службе регистрации в качестве объектов передачи данных.

Я думаю, что меня беспокоит то, как устройство должно быть представлено до его входамое приложение (используя прикладной уровень в качестве точки входа).При отправке устройств из веб-сервисов я передаю последовательность объектов передачи данных устройства.Это отличается от взятия потенциально странно отформатированного файла и его анализа в объекте передачи данных, поскольку отображение запроса веб-службы на объект передачи данных довольно простое и не слишком сложное.

Любые мысли оэто очень приветствуется.

Answer 1

Я бы сказал, что ApplicationService - это подходящее место для логики синтаксического анализа, хотя было бы неплохо поместить его в службу DirectoryWatcher.

Мое обоснование этого утверждения исходит изТочка зрения принципа единой ответственности: в частности, DirectoryWatcher не должен отвечать за управление всеми различными форматами входных файлов.Он должен просто взять то, что он получил, и передать его в нужное место (это уже очень сложная обязанность).

Когда моя голова немного повернулась (что, может быть, так же, как и вы?), Было ли этона самом деле не является обязанностью ApplicationService, который координирует ваши различные доменные объекты.Тем не менее, я чувствую, что ApplicationService - это подходящее место для использования своего рода шаблона Builder, абстрагируясь от деталей каждого метода синтаксического анализа каждого файла, а также создавая ясное место в Домене, где этот анализ координируется.

Что касается каждого формата файла, являющегося частью домена или нет.Я бы сказал, что они - вы можете себе представить, что все они выражаются как часть вездесущего языка, когда различные эксперты в области обсуждают причуды x-формата или y-формата и выраженные данные.Подобный анализ и отображение очень похожи на логику домена первого класса.

Еще одна приятная сторона вашего оригинального дизайна - я думаю, что это упростит добавление новых источников и форматов входных файлов и изменение существующих.Вы отсоединили источник файла от определенного формата и создали красивую интерфейсную точку (ApplicationService), где ваши новые провайдеры файлов получают доступ к основным приложениям.

Answer 2

В соответствии с SRP (принцип единой ответственности), вы должны держать свое рассмотрение. Directory Watcher service должен делать то, что умеет лучше всего - следить за новыми файлами в каталоге и передавать их другому сервису, т.е. Appliance Service, который преобразует их в объекты передачи данных. Теперь вы можете использовать web services для отправки этих объектов передачи данных в приложение.

Я бы сделал интерфейс для Appliance Service, по крайней мере с одним методом с именем Convert(). Appliance Parsing Service класс может реализовать интерфейс. Допустим, позже у вас есть другой источник (SQL) для устройств. Вы можете написать другой класс Appliance SQL Service, который реализует Appliance Service.