0

I'm currently working on a project that heavily relies on external components - mostly physical devices such as routers, switches, NVTs and their respecitive protocols to communicate with (SNMP, Ping, RTSP...). I need to surveillance those devices (are they online? What's their status?) and send operational messages to them. (Start that task, enable this port...)

Unsurprisingly, this is the only domain entity I really need:

public class Device {

    public long IpAddress { get; set; }
    ...

}

But I sure do have a lot of services. Like a ISnmpService, IPingService, IFtpService,... Now I'm asking myself: How can DDD help me here? In which layer do I have to implement those services? Are those even 'real' domain services? Do they belong into the infrastructure layer or would it be fine to implement the services in the domain layer?

And how could such an implementation fix a problem like this:

public HorribleController : ApiController {

    public HorribleController(
          ISnmpService snmpService,
          IRtspService rtspService,
          IPingService pingService,
          IOnVifService onvifService) 
    {
        ...
    }

    public AddDevice(Device device) {
         snmpService.Add(device);
         rtspService.Add(device);
         rtspService.Connect(device);
         pingService.Watch(device);
         onvifService.Add(device);
    }

}
Acrotygma
  • 2,531
  • 3
  • 27
  • 54

1 Answers1

1

Ask yourself the question, does my service contain business logic related to the domain that doesn't naturally belong in an aggregate or value object? If it does then it is a domain service and belongs in the domain. If what you are trying to do is communicate with external systems (ping, ftp) then it is probably and application service or even further out and in the port/adapter ring of the hexagonal architecture. See http://alistair.cockburn.us/Hexagonal+architecture.

JustinS
  • 123
  • 1
  • 7