1

I am trying to design a domain layer with both rich models(anemic models are bad OO practices). I also learned from DDD that it does not exclude service objects, and that a good domain layer design is a healthy balance of domain logic split into both domain models and service objects. I wonder though, if business logic should be divided between domain models and service objects, where should the line be drawn? In other words, how do I know if a business logic belongs to a domain model or a service object? Is there a rule of thumb that specifies that certain behavior should go to domain models while others belong to service objects? Please let me know if you can give even just a little bit of hint, thanks.

Lord Yggdrasill
  • 3,197
  • 4
  • 26
  • 42

2 Answers2

2

Since domain services are a part of the domain model, I assume you mean domain services vs. domain objects.

Toran Billups has give a similar answer here, Jimmy Bogard a nice blog-post here.

As a general rule of thumb: Domain Services are stateless, while domain objects have state. Thus, anything that depends on internal state would go into a domain object, concepts that are do not depend on current state and/or do not conceptually fit to a single domain object are modeled by domain services.

Community
  • 1
  • 1
Alexander Langer
  • 2,883
  • 16
  • 18
  • Knowing that a domain service should not have state does not mean that it cannot check the state of the objects it is using (they can depend on aggregates state they manipulate) . The basic transferFundsDomainService might need to check if one account is opened for transaction, if not , the service will fail. Also Jimmi Bogard has some posts that promote improper design (ie. entity validations). – Geo C. May 19 '14 at 20:30
2

Good domain layer design models properly the domain concepts and use cases. It's up to you to decide what's an aggregate root (AR) and what qualifies as a service. Everyone has their own experience and preferences.

Personally, I use services to implement use cases. This means they have state although pretty immutable, state is an implementation detail (I could write the same thing with static methods passing all the deps as method's arguments instead of injecting the required repositories and other services in the constructor).

The most important thing is to be sure you've understand the business concepts, behaviour and use cases. This should be obvious yet, a lot of people are shallow about it and the resulted design is pretty wrong and hard to maintain.

I suggest to employ a more natural approach. Just start modelling things, don't ask yourself if it's an AR, or value object or it should be a service etc. It will become clear to you as you progress.

The worst thing you can do is to come up with some artificial rules/constraint and model your domain (and the whole app actually) according to those rules. DDD is about letting the Domain drive the design. Terminology and technical details are implementation detail, those can change anytime, don't use them as design guidelines.

MikeSW
  • 16,140
  • 3
  • 39
  • 53