InfoQ has posted "
Domain Driven Design Quickly" online. This book is a summary of Domain Driven Design, meant to be a quick introduction as an alternative to the 600-page tomes available elsewhere - to whet the appetite of those who are looking into Domain-Driven Design.
Is it possible to create complex banking software without good domain knowledge? No way. Never. Who knows banking? The software architect? No. He just uses the bank to keep his money safe and available when he needs them. The software analyst? Not really. He knows to analyze a given topic, when he is given
all the necessary ingredients. The developer? Forget it. Who then? The bankers, of course. The banking system is very well understood by the people inside, by their specialists. They know all the details, all the catches, all the possible issues, all the rules. This is where we should always start: the domain.
When we begin a software project, we should focus on the domain it is operating in. The entire purpose of the software is to enhance a specific domain. To be able to do that, the software has to fit harmoniously with the domain it has been created for. Otherwise it will introduce strain into the domain, provoking malfunction, damage, and even wreak chaos.
Speaking on why DDD is important:
The long-term trend is toward applying software to more and more complex problems deeper and deeper into the heart of these businesses. It seems to me this trend was interrupted for a few years, as the web burst upon us. Attention was diverted away from rich logic and deep solutions, because there was so much value in just getting data onto the web, along with very simple behavior. There was a lot of that to do, and just doing simple things on the web was difficult for a while, so that absorbed all the development effort.
But now that basic level of web usage has largely been assimilated, and projects are starting to get more ambitious again about business logic.
Very recently, web development platforms have begun to mature enough to make web development productive enough for DDD, and there are a number of positive trends. For example, SOA, when it is used well, provides us a very useful way of isolating the domain.
Meanwhile, Agile processes have had enough influence that most projects now have at least an intention of iterating, working closely with business partners, applying continuous integration, and working in a high-communication environment.
So DDD looks to be increasingly important for the foreseeable future, and some foundations seem to be laid.
The book looks good - another online reference of great quality released in the last few days.
