AnemicDomainModel - 0 views
-
AnemicDomainModel
-
Eric Evans
-
basic symptom of an Anemic Domain Model
- ...40 more annotations...
-
The catch comes when you look at the
-
behavior
-
there is hardly any behavior on these objects, making them little more than bags of getters and setters
-
I was chatting with
-
note, the 'i' here, is mr. MARTIN FOWLER!! and of course, eric evans hails from domain driven design fame
-
-
fundamental horror
-
it's so contrary to the basic idea of object-oriented design
-
combine
-
data and process together
-
procedural style design
-
completely miss the point of what object-oriented design is all about
-
It's also worth emphasizing that putting behavior into the domain objects
-
should not contradict the solid approach of using layering to separate domain logic from such things as persistence and presentation responsibilities
-
logic that should be in a domain object is domain logic
-
validations
-
calculations
-
business rules
-
One source of confusion in all this is that many OO experts do recommend putting a layer of procedural services on top of a domain model, to form a Service Layer
-
this isn't an argument to make the domain model
-
void of behavior
-
service layer advocates use a service layer in conjunction with a behaviorally rich domain model.
-
does not contain business rules or knowledge, but
-
only coordinates
-
tasks and delegates work to
-
collaborations of domain objects
-
in the next layer down
-
can have state that reflects the
-
progress of a task
-
for the user or the program
-
Domain Layer
-
Application Layer
-
Service Layer
-
Responsible for
-
representing concepts of the business
-
business rules
-
This layer is the heart of business software
-
... and has the *most value* to an organization investing in writing their own software infrastructure software (eg. user interface, orm, application server-related frameworks) or plumbing code should be treated as commodities where possible, unless, the business consciously decides that a custom, home-grown implementation is absolutely required for patenting or other differentiation reasons and/or that no existing off-the-shelf solution can be used but these cases should be rare! do not blindly fall for the not-invented-here syndrome
-
-
all the key logic lies in the domain layer
-
I don't know why this anti-pattern is so common
-
if they come from a
-
data background
-
this is why during every sprint, i reiterate that the data model up approach to designing the system is OH SO WRONG but nobody listens
-
-
J2EE's Entity Beans
-