DDD - Может ли технология быть частью модели домена, если домен включает технологию?

Question

Я довольно новичок в DDD, поэтому, пожалуйста, держитесь за меня.

У меня есть домен, который специально занимается созданием, редактированием и производством текстовых документов, содержащих данные, связанные с бизнесом. У меня также есть библиотека, которая упаковывает Open XML SDK (. net) и предлагает высокоуровневый API для WordDocument.

Мой пример использования заключается в том, что пользователь может создать такой документ Word ( через соответствующий пользовательский интерфейс WPF), добавьте в него некоторые пользовательские данные, связанные с бизнесом (например, вставьте изображения и текст), а затем, наконец, сохраните изменения и уничтожьте экземпляр. Поэтому мне нужно отслеживать экземпляр слова word в памяти, чтобы справиться со всем этим.

Теперь, следуя пути DDD, обычно я не хочу, чтобы какая-либо технология просочилась в мою модель предметной области, но потом Мне нужно иметь поведение в моем агрегате документов (например, Open (), Save (), FeedData () и т. Д. c.), Которое, конечно, необходимо применить к такому экземпляру слова.

Без ссылок эта библиотека в моем домене, где должен находиться этот экземпляр документа? Должна ли моя соответствующая служба приложений обрабатывать такой экземпляр члена? Но это кажется странным, потому что обычно мои сервисы не имеют состояния и управляют только поведением моих сущностей.

У меня есть сильное желание увидеть требуемую технологию как часть моего домена, и когда мы общаемся с нашими экспертами по доменам, мы фактически говоря о «документах слова», так что это часть вездесущего языка. Я немного сбит с толку, если мое предположение приводит меня сюда не туда.

Я предполагаю, что мой вопрос заключается в том, может ли технология быть частью модели предметной области, если домен (и ее язык) включает технологию?

Answer 1

Может ли технология быть частью модели домена, если домен включает технологию?

Полиция DDD не придет за вами, если вы не сделаете то, что они Ожидайте.

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

Мотивация для разделения: доменная логика c - это отдельная задача от логики приложения c - мы должны быть в состоянии "поднять" и переносит код домена из одного приложения в другое (например, из пользовательского приложения для настольного компьютера на веб-сайт); код приложения имеет тенденцию изменяться по причинам, отличным от кода домена.

Кроме того, при работе в домене logi c полезно в процессе программирования удалить все проблемы приложения из контекста - в нашем доменном коде мы должны сосредоточиться на «что происходит в бизнесе, когда клиент размещает заказ», не отвлекаясь на кучу проблем приложений, таких как «как мне извлечь их историю заказов из базы данных?»

Важный вопрос о вашем документе - это данные снаружи ? или данные на внутренней стороне ?

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

Если это данные изнутри - это означает, что ваша модель домена отвечает за содержание документа, то ваша модель будет знать кое-что об этом. Не обязательно загружать / сохранять - ваша модель, вероятно, не очень заботится о используемом вами решении для сохранения данных, но вносит изменения в саму модель документа, конечно.

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