Inspired by Eric Even’s excellent book, Domain Driven Design,
I have been studying and using domain driven design for a while. There have a lot of advantages offered by implementing DDD in enterprise applications. I will continue to blog what I learned from DDD later. Among those advantage, one of the most important is to clearly lay out the resposibilites for the classs in the doma layer, such as Entity, Value Object, Service, Repository and Fractory. There has a question always in my mind that if we have move application operations to service class. What methods we need to implement for Entity class? We are trying to avoid AnemicDomainModel. So how do we design our Entity class? Here comes the answer:
“The best definition of “domain object” I’ve found in literature is in Chapter
11 of TimHoward’s book TheSmalltalkDevelopersGuideToVisualWorks
pp.379-381:“a domain object is a logical container of purely domain
information, usually represents a logical entity in the problem domain space …
In general, domain objects should know how to
recognize which [of their]
references indicate aggregation and which ones indicate association
copy
themselves
maintain business logic
compare themselves to other domain
objects of the same type
facilitate other objects that choose to print or
display them
conduct tests on their domain information”
To this list I
would add
identify themselves
validate themselves
–RandyStafford
I would also
add
domain objects direct their persistence
there may be collections of
Domain objects
domain object may contain references to other domain objects
(this is assumed by the first one above).
–Fritz Schenk “
Quote from http://c2.com/cgi/wiki?DomainObject
