Based on DDD practices, where should this logic go and how do I avoid unnecessary dependencies?

Question

I'm adding some logic to my web app to lookup geo-coordinates for a user, store them, then using those coordinates lookup the timezone and store that. My first go at this was to add a GeoCodeUser() method to a MappingService i had defined to do other map-related tasks. Because looking up the two bits of data relied on two different REST services, I broke the two lookup tasks into AddressGeoCoder and TimeZoneCoder and used those to retrieve the data and the UserRepository to store them. The odd part of this solution is that though this method needs access to the repository and two 'coders', the other methods in the class didn't. So every time I use that service to do other things I'm getting dependencies I don't need and then dropping them. So here is what I am wondering:

• Should this be in a service (since it's coordinating different operations) or possible in the 'User' model object itself?

• If so, should I be defining a service based on it's dependencies & area of interest (i.e. UserGeoCodingService), or just area of interest (MappingService) with extra dependencies?

Thanks so much for your insight!

James

Answer 1

IMHO, DDD is all about the MODEL, and expressing how the domain experts say things work. I don't really know much about this domain, so I can't point out for sure what makes more sense. You will need an expert or a consistent model to base on. If you don't have a model yet, just stop coding now, and go build your model.

First, you need an ubiquitous language to help you have a better insight, creating the classes accordingly. Does the separation based on area of interest only makes more sense for the domain experts?

How do domain experts explain the process? Do they use terms like AddressGeoCoder, TimeZoneCoder? If so, then it is a good design. Otherwise, you better get to know how they think.

About the class, that has only one method that uses a repository and two coders, there are a few possible ideas (see or create one which makes sense FOR THE DOMAIN).

• Only the method receive its dependencies from the parameters
• Extract this method to some other class (like a service, as you said)
• Summarize this 3 entities in only one (like GeoCodeUserData, again, if this makes sense for the domain)
• Use a dependency injection framework to avoid extra work including these dependencies
• Let your constructor accept nulls (and deal with errors the same way a domain expert say it should be done)
• Whatever idea you else have, validated by a domain expert

DDD is an intense work of refactoring also, once you get better insight of the domain, so it's good to have tests for stuff, so you won't be afraid of making the necessary changes.