Откуда логика внешнего устройства в дизайне, управляемом доменом?

Question

Я пытаюсь разработать новый проект с точки зрения более предметной области, и хотя я в основном понимаю принципы, некоторые вещи все еще намекают на меня.

Мой домен требует взаимодействия с внешними устройствами, и поэтому мне нужно определить интерфейсы для обнаружения устройств, создания моделей и в некоторой степени связи.

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

Чтобы добавить немного больше информации, в настоящее время у меня есть архитектура, смоделированная следующим образом:

* Domain (references nothing)
  + IDiscoverDevices (device discovery interface)
    - BeginDiscovery: void
    - EndDiscovery: void
  + IDeviceProvider (factory for device creation)
    - Make: IDevice
  + IDevice

* Framework (references Domain)
  + DiscoverDevices
  + DeviceProvider

* Client (references Domain and Framework)
  + SomeView (takes IDiscoverDevices, IDeviceProvider via ctor)

Answer 1

Используя принцип инверсии зависимостей, ваши интерфейсы будут определены в домене, но они будут реализованы на уровне инфраструктуры.

Answer 2

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

Контекст логики внешнего устройства должен быть интегрирован в контекст вашего основного домена, используя некоторый уровень перевода, например, используя уровень защиты от коррупции. Обратите внимание, что Антикоррупционный уровень является частью контекста основного домена и поэтому должен абстрагировать модель внешних устройств на языке основного домена.

Это, конечно, не общее решение, но предполагается, что доменно-управляемый дизайн действительно применим для вашей проблемы, т.е. ваш основной домен сложен с большим количеством бизнес-правил, которые обеспечивают конкурентное преимущество для вашего бизнеса. Если это не так, вы не должны использовать DDD, а использовать что-то более простое, например, используя принцип инверсии зависимости, такой как plalx, ​​предложенный в его ответе.