And since then my application is back to having all the logic in Service layer.
There are two things that you can do here.
The key idea is that “retrieving data” is a completely different concern from “processing” data. Retrieving data needs IO, so that concern is normally managed by your application components. Processing data is a problem for your domain logic.
So we use application code to get the data, then pass the in-memory representations of that data to the domain code.
One approach is to treat “retrieve the data” as something analogous to a domain service. So the domain model defines some interface that describes an implementation agnostic retrieve of the data, and the application implements an instance of that interface, wired up to the correct IO mechanism. For use cases that need the remote data, the interface of the aggregate root includes in its target method(s) an argument of the appropriate interface.
In effect you “dependency inject” the application’s implementation of the interface into the function.
An alternative approach is to have the domain model ask for the data it needs, which the application service retrieves and passes to the domain model as a value. So all of the IO concern lives in the application component, and the aggregate root acts like a little state machine that tells the application what it wants.
switch (root.state()) {
case I_NEED_DATA:
data = getTheData(root.args())
root.onData(data)
break
//....
}
See Cory Benfield’s talk on Building Protocol Libraries to get a broader sense for how this might work.
If the distinction between the two styles in unclear, you might reflect on how you would write an isolated test for your domain code in each case. Using the first pattern, you would end up passing a test double (aka a “mock”) to the logic under test. In the second pattern, you would end up passing plain old data (because all of the I/O that you would otherwise need to mock away is invoked by the application code, not the domain code).
