Domain Driven Design is a vision and approach for dealing with highly complex domains that is based on making the domain itself the main focus of the project, and maintaining a software model that reflects a deep understanding of the domain. The vision was brought to the world by Eric Evans in his book "Domain Driven Design". Eric's work was based on 20 years of widely accepted best practices in the object community, as well as Eric's own insights. Included in the InfoQ minibook Domain-Driven Design Quickly, was an interview with Eric Evans, published separately as an article to get more viewership.
Read Eric Evans on why DDD Matters Today.
In the interview, Eric Evans puts DDD into modern context and explains why DDD is relevant today, how DDD fits into today's development platforms (Java, .NET, etc), and what's been new in the DDD world since 2003.
At the recent Spring Experience conference, InfoQ did a video interview with Eric which will appear on InfoQ in the coming months. One of the questions answered was what are the minimal practices required for one to say they are doing DDD? Eric responded that the two main ones are using the ubiquitous language, and also the bounded context pattern.
Read Eric Evans on why DDD Matters Today.
In the interview, Eric Evans puts DDD into modern context and explains why DDD is relevant today, how DDD fits into today's development platforms (Java, .NET, etc), and what's been new in the DDD world since 2003.
At the recent Spring Experience conference, InfoQ did a video interview with Eric which will appear on InfoQ in the coming months. One of the questions answered was what are the minimal practices required for one to say they are doing DDD? Eric responded that the two main ones are using the ubiquitous language, and also the bounded context pattern.
/filters:no_upscale()/sponsorship/topic/d7295235-717e-4e53-b057-e8f2b20f7838/MicrosoftLogoRSB-1650524400057.png)
/articles/creating-http-sdks-dotnet-6/en/smallimage/logo-1643921705305.jpg){kind=logo}
/articles/microservices-concepts-patterns/en/smallimage/Microservices-the-letter-and-the-spirit-small-image-1637327649178.jpg)
/articles/colors-dotnet-guide/en/smallimage/logo-1643054532698.jpg){kind=logo}
/articles/getting-started-grpc-dotnet/en/smallimage/logo-1638894843213.jpg){kind=logo}
/articles/native-compilations-boosts-java/en/smallimage/article-series-native-compilations-boosts-java-small-1649686214768.jpg)
/articles/native-java-micronaut/en/smallimage/cloud-native-java-micronaut-framework-small-1650531212121.jpg)
/articles/data-with-quarkus-kafka/en/smallimage/UaUXvhM4-1651071035514.jpg)
/articles/native-java-real-world/en/smallimage/native-java-in-the-real-world-small-image-1649775707084.jpg)
/articles/native-java-quarkus/en/smallimage/kubernetes-native-java-with-quarkus-small-1649232064181.jpg)
/articles/native-java-graalvm/en/smallimage/revolutionizing-java-with-GraalVM-native-image-small-1648805051420.jpg)
/articles/tools-for-jakarta-ee-devs/en/smallimage/logo-1648646279253.jpg){kind=logo}
/articles/problem-reframing-method/en/smallimage/logo-1646680413270.jpg){kind=logo}
/articles/java-performance-tornadovm/en/smallimage/logo-1646667233753.jpg){kind=logo}
/minibooks/angular-mini-book-v2/en/smallimage/angular-book-s-1645176541549.jpeg)
/articles/java-jvm-trends-2021/en/smallimage/InfoQ-Trend-Report-logo-1641794256028.jpeg){kind=logo}
/presentations/java-fast-release-cadence/en/smallimage/qcon-plus-s-1640192096828.jpg)
/articles/six-features-jdk12-to-jdk17/en/smallimage/six-features-from-Java-12-to-17-to-get-excited-about-small-1639487914685.jpg)
/articles/java-external-rules-engine/en/smallimage/logo-1637682106961.jpg){kind=logo}
/articles/introducing-kivakit/en/smallimage/logo-1637780334611.jpg){kind=logo}
/presentations/java-update-versions/en/smallimage/Marc_Hoffmann-s-1637581262221.jpg)
/presentations/fire-code-software/en/smallimage/laura-nolan-taxonomy-black-swans-s-1650222535389.jpeg)
/articles/managing-technical-debt-microservices/en/smallimage/logo-1643626223282.jpg){kind=logo}
/articles/psychological-safety-tech-teams/en/smallimage/psychological-safety-tech-teams-image-small-1649851511472.jpg)
/articles/continuous-portfolio-management/en/smallimage/logo-1647267787627.jpg){kind=logo}
/articles/emergence-scafolding-complexity/en/smallimage/logo-1646082392339.jpg){kind=logo}
Community comments
Domain Driven Design - is that something new or just well forgotten?
by David Rozenberg,
Re: Domain Driven Design - is that something new or just well forgotten?
by Randy Stafford,
Re: Domain Driven Design - is that something new or just well forgotten?
by David Rozenberg,
Domain Driven Design - is that something new or just well forgotten?
by David Rozenberg,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Re: Domain Driven Design - is that something new or just well forgotten?
by Randy Stafford,
Your message is awaiting moderation. Thank you for participating in the discussion.
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
Re: Domain Driven Design - is that something new or just well forgotten?
by David Rozenberg,
Your message is awaiting moderation. Thank you for participating in the discussion.
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).