Where does external device logic belong in domain driven design?

Question

I am attempting to develop a new project from a more domain driven perspective and whilst I mostly understand the principles a few things still allude me.

My domain requires interaction with external devices and therefore I need to define interfaces for device discovery, model creation and to an extent communication.

Does stuff like the above belong in the core domain, or from a domain driven perspective does stuff like this (which aids my domain but is not my domain per se) sit outside the domain entirely and use the behaviour defined within the domain to do work?

To add a little more information, I currently have the architecture modelled similar to as follows:

* 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

Using the Dependency Inversion Principle, your interfaces would be defined in the domain, but they would be implemented in the infrastructure layer.

Answer 2

If it aids your domain but is not part of your domain per se it is not part of the core domain but part of a supporting subdomain. Different subdomains should usually be modeled in seperate bounded contexts. So you should have at least two models: one for your core domain and one for your supporting subdomain (the external device logic).

The context of the external device logic should be integrated in the context of your core domain using some translation layer, for example using an Anti Corruption Layer. Note, the Anti Corruption Layer is part of the core domain context and therefore it should abstract the model of the external devices in the language of the core domain.

This is of cause not a general solution but assumes that Domain Driven Design is really applicable for your problem, i.e. your core domain is complex with a lot of business rules which provides competetive advantage to your business. If this is not the case you should not use DDD but use something simpler, e.g. using the Dependency Inversion Principle like plalx suggested in his answer.