Details
-
Type:
Improvement
-
Status:
Resolved
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 2.0
-
Component/s: DSL for Business Domain, DSL for Services
-
Labels:None
Description
The DomainServiceImplBase classes explicitely call an update method on the DAO. However, since we use Hibernate this method is not implemented and could as well be left out. Then the update functions in the DomainServiceImplBase classes can also be removed.
To take this argument one step further; I consider these functions dangerous. They hinder a good OO design. Suppose I make an invoicing system. When I modify a (draft) Invoice, for example change an OrderLine, a lot might happen. Maybe some aggregates are calculated and the customer account is updated. This logic should be implemented in the domain model. But if the updates of the modified objects have to be persisted by the DomainService, how does that class know what happened? What if there is complicated conditional logic leading to state changes in the domain model? The domain service shouldn't care.
Issue Links
- depends upon
-
MODFORJ-102
Overcomplicated layering / DDD
-
- relates to
-
MODFORJ-114
Persisted objects within a Hibernate session do not need to be explicitly updated
-
Managing the persistence life-cycle of objects (creating and deleting them) should be possible from the domain model. When, how, under what conditions a (persisted) object should be created or removed is domain logic. Domain objects should be able to call life-cycle management methods on the DAO/Repository to achieve this.