Я пытаюсь обернуть голову вокруг концепции управляемого доменом концепции уровня сервиса, как приложений, так и служб домена. Практически все примеры, с которыми я столкнулся, связаны с приложениями CRUD с базами данных. У меня возникли проблемы с пониманием того, как эти понятия сопоставляются с графическими приложениями, такими как пример приложения, который я выбрал для этого вопроса, клон Microsoft Paint, разработанный в .NET/C#.Услуги доменных служб и приложений для графических приложений
Я прочитал basic concept of a service layer in DDD и expanded explanation. Я выбрал следующие слои применения:
Инфраструктура (сквозная)
- Протоколирование
данных (файловая система)
- BitmapImage, PngImage и т.д.
Домен
- Холст, изображение, выбор, форма, кисть и т.д.
Применение
Презентация (локальный клиент WPF)
- Просмотров
- ViewModels
В одном случае, который я пытаюсь создать, пользователь рисует прямоугольник на холсте. From what I've read, поскольку для использования требуется сотрудничество нескольких доменных объектов, служба домена, DrawingService, имела бы смысл.
Другим вариантом использования будет пользователь, загружающий файл для отображения. Опять же, from what I've read, так как этот вариант использования - это команда и рабочий процесс, служба приложений FileLoadingService будет иметь смысл.
As Martin Fowler describes, я считаю, что Microsoft Paint достаточно сложна, чтобы гарантировать подсистему обслуживания, здесь основанную на тематическом поведении. Однако по мере того, как приложение растет, уровни обслуживания могут быть реорганизованы, чтобы попасть в разделы модели домена, например. CanvasService, SelectionService и т. Д. Если бы тогда потребовался еще один уровень абстракции, perhaps an application facade, теперь, когда несколько служб должны сотрудничать?
Update 1:
Первоначальные комментарии предполагают DDD архитектура не подходит для применения рисования. Любые предложения по альтернативе?
imho приложение для рисования не очень подходит для DDD. Он использовал бы что-то другое. – jgauffin
Я согласен. рисунок - хорошо понятый и смоделированный домен, и нет никаких оснований пытаться адаптировать к нему тактические инструменты DDD.попытка этого приведет к трению; основная причина заключается в том, что большинство инструментов DDD ориентированы на архитектуру клиент-сервер, сложную методологию сохранения, ни одна из которых не связана с программой рисования. – eulerfx
В большинстве случаев, если вам не нужен эксперт домена, вам не нужен DDD. –