Complex Business Domains
When software is developed for a business with where the domain is complex, new systems often fail to account for this complexity in the core parts of the business. This leads to lost opportunities to mine the richness of the domain and encode it in the software itself, resulting in systems that are brittle and difficult to change along with the business as it grows and adapts to new market opportunities.
Domain-Driven Design (DDD) is a philosophy and approach to developing object-oriented systems for businesses with highly complex domains. The central idea is to develop a rich domain model and express it as clearly and rigorously as possible in the software itself. The central ideas for DDD were developed by Eric Evans and published in the “big blue book”: Domain-Driven Design: Tackling Complexity in the Heart of Software in 2004.
DDD is a fundamentally different approach from the more typical forms-over-data application approach, often using the ActiveRecord pattern made so popular with Ruby on Rails, that businesses tend to adopt when developing standard business applications. DDD advocates for domain modeling as the central focus of development, and thus considerable effort to be expended in encoding the richness of domain behavior into the heart of the software itself. I will expand on this in future posts.
Recommended DDD Books
For those wanting an introductory text, go to InfoQ and download Domain-Driven Design Quickly (104 pgs, pdf). The text is a free download, and the print version is available for purchase for $30.
I have used this book very successfully as my standard introductory text on DDD for new developers. The big blue book can be a lot to bite off for someone, and DDD Quickly dramatically eases the spread of ideas throughout the team.
I also have used it as a great “bridge-text” for business analysts (BA’s), testers and other non-developers on a project where DDD principles and practices are being applied. Business analysts will really appreciate the increase in communication that developing a ubiquitous language for expressing system behavior.
Developers working in .NET that have read Eric’s book and are looking to go deeper can find a helpful companion in Jimmy Nilsson as he walks through many practical examples in Applying Domain-Driven Design and Patterns: With Examples in C# and .NET.
This book was a tremendous help to me as I initially struggled to understand DDD distinctives and apply them to the problems I was trying to solve. It also has good examples of applying Test-Driven Design and UI design patterns in the context of DDD.
Another good source of information is the Domain-Driven Design community website. This has a good list of resources, including links to presentations and webcasts, as well as examples and links to local communities.
For an ever-growing list of DDD resources see my Delicious bookmarks on DDD .
Finally, I did an introductory presentation on DDD at IASA Denver last year (thanks again to Dave Laribee for giving me permission to adapt some of his ideas for this presentation):