Where do long running, stateful 'services' fit in DDD?

Question

In more industry or automation related applications (that mostly heavily rely on external components which they have to manage), you'll often end up with the case that the domain contains models which are more than just abstractions from the real problem, but also representations of and pointers to something that physically exist outside of the domain.

For example, take this domain entity that represents a network device:

public class NetworkDevice {
   public IPAddress IpAddress { get; set; }
}

Instead of just storing or validating such entities or taking actions upon entity changes, an application may need to manage external components based upon their representations inside the domain. Now, is DDD even suitable for such cases? Are those managers domain services?

Eric Evans describes in his famous blue book that a domain service needs to be a stateless model implementing methods taken from the ubiquitos language to fullfil a request that the entity, or a repository cannot handle by itself. But what if a service needs to be stateful?

A simple example: An application needs to monitor configured IP devices within the network in order to notify other application inside the domain about state events. If a IP device gets registered inside the application (stored inside a database, for example), a "ping-service" gets notified and starts to monitor the device.

public class PingMonitor : IDisposable,
   IHandle<DeviceRegisteredEvent>,
   IHandle<DeviceRemovedEvent> 
{

    public List<NetworkDevice> _devices = new List<NetworkDevice>();

    public void Handle(DeviceRegisteredEvent @event) {
        _devices.Add(@event.Device);
    }

    public void Handle(DeviceRemovedEvent @event) {
        _devices.Remove(@event.Device);
    }

    public void PingWorker() {
        foreach(var device in _devices) {
            var status = Ping(device.IpAddress);
            if(status != statusBefore)
                DomainEvents.Raise<DeviceStateEvent>(new DeviceStateEvent(device, status));
        }
    }

}

Other components could then handle those status events and e.g. stop talking to the device via other protocols if the device goes offline.

Now, what are those components? At first I thought they are domain services because they serve a certain requirement of the domain. However, they are stateful as well as do not specifically represent the ubiquitos language (the task of a ping-service is to ping a domain entity and report it's status, however the ping-service does not implement a method that would clients allow to ping a device).

Are they application services? Where do such components fit inside the DDD pattern?

Answer 1

In DDD a long-running process is called Saga. It's typically implemented using Domain Events.

Here's some introduction to the topic: http://abdullin.com/journal/2010/9/26/theory-of-cqrs-command-handlers-sagas-ars-and-event-subscrip.html/