DomainDrivenDesign
Last edit January 17, 2011Domain Driven Design by EricEvans
ISBN 0321125215 about DomainModelling
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 patterns: http://domaindrivendesign.org/discussion/messageboardarchive/MessagesByTopic.html
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: BoundedContexts, AnticorruptionLayer, ConformistStrategy, SeparateWays, SharedKernel.
CategoryBook CategoryDesign
ISBN 0321125215 about DomainModelling
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 patterns: http://domaindrivendesign.org/discussion/messageboardarchive/MessagesByTopic.html
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: BoundedContexts, AnticorruptionLayer, ConformistStrategy, SeparateWays, SharedKernel.
CategoryBook CategoryDesign