What goes in your domain model objects and what goes in your services?

Question

In a domain driven design where you\'re going for a non-anemic domain model how do you decide what to implement in your domain objects vs. service oriented methods?

Answer 1

The idea of DDD is that the domain model contains your data and most of the business logic. The services normally deal with persistence of these structures.

Then there's all those in-between cases where the business process consist of multiple steps that invariably change/modify the domain objects. You're normally using services to realize some process. So normally you are updating the domain objects with results from the services. You never let the domain object implementations call services by themselves !

So its quite common to see code like this:

if (order.isValidForPurchase() && orderValidatorService.isValidOrder( order))
    orderService.order( order)

Simply because parts of the truth is known to the order object, and some requires external data known to orderValidatorService. Arguably these two lines of code could also be inside the orderService.order method.

I think it's always worthwhile to investigate HOW many domain objects exist in these processes;sometimes a lot can be gained by making more concepts than you initially think. It's really the intersection of business process states and object models. Often DDD models tend to try to capture the domain from a overly structural view, IMO disregarding core processes a little too much. So if you're overly structural I think you make an Order object. If you add process maybe you make ShoppingCartOrder, UnshippedOrder, ShippedOrder, BilledOrder and HistoricalOrder. This also makes your service integration simpler sometimes.