- Why do people use it?
Two things happen at the DDD entity level. One is to ensure that your objects do not get into an invalid state, the other is to bring related functionality into the entity it is related to, such as order processing methods on a customer entity.
The part I do not get is that already use view models to overcome missmatches between entity properties and the values we need to display. These view models are then validated on post. Therefore, it seems redundant to force entities to have parameterized constructors.
Furthermore, in all the examples I’ve run across, such entities go to the trouble of having such a parameterized constructor, and then expose the property as a public get and set value, forgetting about future assurances that the value will be valid.
If we strip our entities of this behaviour, all we are left with is properties and a few methods. But what about those methods? We’ve already delegated out the responsibilities of display and validation to different things, why then leave shape and affect together? Would it not make more sense to pull these business methods out and use them in a service class instead?
If we do, we’re back where we started: view models, validators, services, and data models.
So tell me again…what purpose does ddd serve?