Sun Apr 27, 2003 6:04 pm
Domain driven design addresses the modeling/structuring of
the "business object tier" of a system ... developing a
deeper understand about the domain and modeling the
software around the "guts" of the domain ... I can see how
this results in a flexible design - the model mirrors what's
happening in the real world and if things change it maps
nicely into the model making the change "natural", easier,
i.e. the design is flexible.
I am interested in some thoughts / comments on is how this
relates to functional application design: One approach to
get this right is the use case driven approach - trying to
work out what users actually want to accomplish with the
system and using this as the driving force for the modeling.
Use cases often often cross multiple "business objects", so if
you use them to drive the design, you end up with different
underlying model than using the DDD approach - the result
is software which is tailored to user needs but is less
flexible.
It seems you need to need both approaches - use cases for the
application flow (and presentation layer follows from there)
and domain analysis for the business logic layer (and data
layer follows from there). Question is, which model should be
the driving force? Also, if you need both models, how do you
synch them up?
I guess one idea is to use the use case model to verify the
domain model?
Am very interested in comments, insights ...
Cheers,
RobertSchulz
I think this question implies that you are looking for a
mechanistic solution. Why should either use cases or
the domain model dominate? That is like asking whether
your life should be dominated by the need for food or
by the need for shelter. A use case driven approach is
best at the beginning of a project, when you don't know
the domain that well. Use cases are always helpful for
explaining the system to others. But the real goal of
the process described in the book is to develop a language;
first a human language shared by developers and their customers
and then a language used to describe the system to the computer.
Use cases are a tool for helping us understand a system, but
the real goal is the understanding, not the use cases.
This book is not about developing a system in six months.
It is about developing a system over the course of several
years, continuously adding features as the customers request
them. It is as much about how to maintain a system as it
is how to develop it in the first place.
RalphJohnson
DomainDrivenDesignAndUseCaseDrivenApproach is mentioned on: ThreadView
