Domain Driven Design
A discussion group has been formed see: http://groups.yahoo.com/group/domaindrivendesign/
A wiki is to be set up -- for more information : http://domaindrivendesign.org/discussion/index.html
A catalog of the DomainDrivenDesign
This book describes how to build business software so that the software clearly
expresses the domain model. It is not just about design techniques, it also talks
about how to organize the developers. It nicely complements books like PatternsOfEnterpriseApplicationArchitecture
because it is light on techniques for
handling concurrency and persistence, and focuses on describing the domain. It is
full of examples and clever pictures and is a lot of fun to read, and it is obvious
that the author knows what he is talking about.
This is a HolyWar
title if I ever saw one. Everyone thinks their favorite paradigm or technique better maps to the domain. There are no consensus metrics for comparing what maps to the domain and what doesn't. Futher, how the domain is perceived often depends on an individual's psychology, and the further the domain is away from the physical world, the more mental model variations there are. In various debates we cannot even agree on the likely patterns of future change, so "better able to handle change" does not settle anything either. And whether to model customer's archaic ideas or help them "upgrade their head" is also an open issue. I have seen some pretty stupid processes in place, but was forced to automate them as-is and cringed the whole way. I had to shower for days.
It sounds a lot like you need to read this book.
Among other things DDD describes various strategies for MultipleModels
EditText of this page
(last edited January 17, 2011)
or FindPage with title or text search