Right about now I can hear murmurs, "I haven't seen any code yet"
That is because I view Domain Driven Design firstly as a design methodology, secondly as an architectural style, and lastly as some great software patterns.
I don't believe I am alone in that view, after all it is a significant way into the book before anything resembling UML appears, and even further before anything code-like is introduced.
Now you could pickup the book, extract some of the key terms and half a dozen patterns, and undoubtedly you would be writing better software ... but I suspect you may have missed the "wood for the trees" or put another way "You spent so much time focusing on the details, and missed the bigger picture"
DDD is a better way of thinking about software design, it helps you translate what users and businesses need into software that meets those needs. The patterns may make your software more stable or more maintainable, but it is the methodology that guides you to deliver something fit for purpose.
Of course, eventually you are going to need some code, as a comment on my last post indicated. I am going to postpone that for a while I am afraid, I apologise in advance if anyone is eager to get typing. We have a few more fundamentals of DDD to explore first, then I promise I will start to delve a little into how to best implement these things in C# code.
Previously:
1) Domain Driven Design: A Step by Step Guide
2) DDD: The Ubiquitous Language
3) DDD: Bounded Contexts
4) DDD: There Is No Database
5) DDD: Command Query Separation as an Architectural Concept
6) DDD: Entities and Value Objects
Reference:
InfoQ Free eBook : Domain Driven Design Quickly
Domain-Driven Design: Tackling Complexity in the Heart of Software (Eric Evans)
del.icio.us Tags: DDD,Domain Driven Design,Practices and Principles
Posted
02-14-2009 5:28 PM
by
Jak Charlton