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

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

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

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

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

* 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)

источник

2014-11-18 Unflux

Мы обсуждаем использование DDD в аналогичном контексте. Мы склоняемся к тому, чтобы не использовать DDD, поскольку в нашем случае мы не видим реальной бизнес-логики. Мы просто предоставляем клей, который соединяет устройства, которые, вероятно, можно считать бизнес-логикой. –

@ ChristopheHerreman - Я начинаю приходить к аналогичному выводу относительно использования DDD, и, честно говоря, моя более поздняя разработка была меньше, чем домен. Дальнейшее исследование использования и преимуществ DDD предполагает, что оно не так полезно в контексте, где есть более техническая логика, чем бизнес-логика, такая, как мой проект. – Unflux

Было бы здорово, если бы ppl перестанет думать о DDD как еще один молот. DDD - это мышление, когда вы пытаетесь моделировать вещи и идентифицировать _if_, у вас есть домен, в котором вы используете DDD. Если ваше приложение является всего лишь компонентом для склеивания, то все, что моделирует его концепции, структуру и поведение, это ваш домен. – MikeSW

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

источник

2014-11-18 13:54:26 plalx

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

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

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

источник

2014-11-24 21:31:48 zebra

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

ответ

Смежные вопросы