I practicing DDD concepts on smaller applications and I use to have the same problem when I have to rely on data coming from outside the domain.

In a previous project, when I wrote an appointment scheduler the appointment could not be cancelled after due date 5 am. So cancelling appointments was dependent on the actual time, which we can call an external dependency. As far as I remember I did something like `TimeSercice.canBeCancelled(appointment.getDate())`, to cover that 5 am rule, but I am not sure if that was the proper solution. It just seemed important enough to include this rule into the domain, especially because it was part of the user stories. Maybe I was wrong.

Now I face something similar. I write an application, which downloads data from an external service every 30 mins. It is something like downloading probabilities for a GPS grid and if the probability by the user's GPS coord reaches a threshold, then it sends a notification to the user, that something is happening. For now I write it as a native mobile application, but I might move most of the code into a webservice later to make it more reliable and reduce the data traffic. What I thought of is doing something like `ProbabilityService.probabilityForPosition(user.getPosition())` to get the probability for the user's position. So that would hide the HTTP calls, parsing the data, etc.

I define the interfaces of these services inside the domain, but the implementation is not part of the domain. I use to inject these kind of dependencies. As far as I remember I injected it by the appointment scheduler from the repositories into the domain objects. Is this a valid approach or DDD follows a different logic if it comes to external dependencies? If so, then why?