I have a situation where my business logic depends on data coming from an external service. I initially though this would be a prime candidate for a domain service, but now I’m starting to wonder if that’s even needed. With years of working mostly with relational database for fetching data, I think my brain may be stuck in a pattern that’s not really helpful. Theoretically, whether the data comes from a database or other SOAP/external service doesn’t matter, right? What matters is if this is a key part of the aggregate, which I believe it is. There is also database data that’s relevant, so it’s a mix.
My guess is that while the domain service could technically be OK, I could also create a repository that fetches the data from both the database and the external service, building my aggregate (probably using a factory to be safe). I can then encapsulate all the business logic within the aggregate itself instead of using a domain service.
The disadvantage of this is that my business object is now somewhat coupled to an external service (I say somewhat because technically the object is a plain object, but there’d be no way of constructing one in the context of the app without using the external service), but the fact of the matter is that it needs to be coupled, there’s no way for the behavior/methods I need for this object to work if the external service is not up. It’s critical to enforcing business rules.
So is there anything wrong with this approach that I’m not thinking of? Any major drawback that would mean using a domain service is a better approach? My assumption would be I’d need a domain service if whatever I need to do has to involve multiple aggregates, but if not I can keep it within the aggregate itself.
Go to Source