Eric Evans on why Domain-Driven Design Matters Today

In mid-1980s the AI community was excited about the problem that would allow to determine that minimum set of software applications that would allow to cover all known and posiible future tasks to be solved in the domain. There were theoretical and practical works in this area, but the problem was not solved. The DDD book and the one which is called 'DDD Quickly' actually do not explain the concept, but switch to the 'micro' design patterns that can help with solving minor tasks in the domain, but do not solve the problem of constructing the domain nor extracting it from the domain experts. Collecting domain artifacts does not allow to construct the domain model unless we can prove that we have the full set of the artifacts for the domain. I do think that the book content actually switches the topic and instead of discussing the fundamentals of DDD it spins on some minor details.

Neither. DDD is an architectural style that is well-remembered and well-practiced by software developers who came from the Smalltalk tradition of the late 1980s and early 1990s, and now is growing in popularity among the Java and .NET generations. Eric has done a wonderful job of putting into words the essence of that timeless object-oriented tradition of how to architect software systems, while at the same time incorporating wisdom gained with experience in areas such as persisting objects and fine-tuning the allocation (factoring) of responsibility.

The DDD philosophy is basically antithetical to the "general problem solver" notion of the AI community you cite - DDD is not reductionist like that. Instead it encourages practioners to implement useful models of specific problem domains, needed for the purpose at hand (e.g. the application under construction). Sure, breakthroughs to valuable generalizations are very gratifying in DDD, but simple elegant craftsmanship is more more the goal than ultimate generalities or frameworks.

Randy Stafford
c2.com/cgi/wiki?RandyStafford

Randy,
Your comments reminded me some conversation I had long ago with one software developer that presented his software at the exibition. It was obvious that he could easily extend the capabilities and have much more functionality in the application. When we asked about that he answered that he was not paid for that. When the customer would require any extended capabilities the customer would need to pay for that and the developer would create another application.
So, the statement that craftsmanship can help is correct to the extent that you can craft something relatively simple and for very specific needs.
When you are required to provide more capabilities, in that case you will need to redo most of what was developed before (if the original design did not take into account possible extensions).