I've a domain in which I need to import and process several aggregates from an external data source, and by running a shell command for each of them.
Let's say a Patch AR representing a patch that need to be applied on the local filesystem. The Patch AR are build from primitives comming from an external data source, and once imported, need to be applied on the filesystem by executing a shell command. The question here is, how I should model the fact to apply the patch by running a shell command? Does the Patch AR can provides a method relying on a domain service such as apply(IPatcherService $patcherService), which would be implemented in the infrastructure layer?
Does the Patch AR can provides a method relying on a domain service
You can do it that way, but as a rule I prefer to leave those details out at the application layer.
The domain layer is bookkeeping; it tracks which things have already happened on the file system and what's supposed to happen next... but the code that actually talks to the file system is out in the applications somewhere.
Review Mark Seemann's Async Injection talk, or Cory Benfield's Building Protocol Libraries the Right Way.
From my point of view, the fact to apply a patch of the filesystem is part of the domain model (Patching System), not just an implementation detail. Why ? because the result of the shell command will change state of the Patch (applied/unapplied). I want represent that fact in my model and that why I want add such interface. Now, I can be wrong somewhere
I don't believe this changes the principles -- your domain model is still bookkeeping about effects that happen "somewhere else". The fact that your somewhere else happens to be "the filesystem on disk" really doesn't change that.