Domain-Driven Design: A Historical View

The history of computing is a domain all unto it’s own. The context of this evolution is worth highlighting by first zooming out to the inventions that came before DDD. Then looking to programming as a field of experiments and inventions, we can consider DDD in light of those preceding inventions. This can help us form a deeper understanding of where the future of DDD and software is headed.

Timeline

Future

1822
First Computer Designed by Babbage

Charles Babbage proposes a machine that could calculate math by a “method of differences”, later dubbed the “Difference Engine”, to the Royal Society. The machine was in development when he refactored the idea to a much more grand undertaking, an “Analytical Engine”.  Later, the Difference Engine was built to his exact specifications, but not until 1991. If you process this well, you begin to understand how timeless a design can be for a domain concept.  The design could have long passed on, and the design still hold value. Why did it take so long? The design was solid, the technology was not available to build it until the next century. This does highlight the power of a quality design that provides a robust solution to a well understood problem.

1937
Binary Computing Invented

Dr. John Vincent Atanasoff envisions the more flexible base of a digital system, the binary base.  Prior, calculators were mainly base 10. Several years later, a student of his, Cliff Berry helps Atanasoff build the first binary computer, the Atanasoff-Berry Computer (ABC) and completed it in 1942.

1951
UNIVAC – The First Commercial Computer

During the war many computers were made for the government to take advantage of the power of these machines, but the first computer known to be sold commercially was the UNIVAC. It weighed 16,000 pounds and had 5,000 vacuum tubes.  It could do 1,000 calculations per second.

1963
Software Engineering – A Named Discipline

The date is a bit fuzzy, but during the Apollo program that would eventually land mankind on the surface of the moon, Margaret H. Hamilton of MIT is credited with coining this term.  Her motivation reportedly was to give a legitimate level of respect to those who designed software, the same level as those who designed hardware. But not all have been as enthusiastic about the term.  For instance, “Individual commentators have disagreed sharply on how to define software engineering or its legitimacy as an engineering discipline. David Parnas has said that software engineering is, in fact, a form of engineering. Steve McConnell has said that it is not, but that it should be. Donald Knuth has said that programming is an art and a science. Edsger W. Dijkstra claimed that the terms software engineering and software engineer have been misused and should be considered harmful, particularly in the United States.” (https://en.wikipedia.org/wiki/Software_engineering, July, 6th 2023)

1966
Object Oriented Programming Invented

In the 1960’s Alan Kay studied biology, philosophy, and electrical engineering among many of his interests.  Kay reportedly coined the terms “object” and “class” to reference these aspects of his programming, while working on the Simula 67 programming language at the Norwegian Computing Center and the rest is history.  However, Kay says, “I’m sorry that I long ago coined the term “objects” for this topic because it gets many people to focus on the lesser idea. The big idea is ‘messaging’.” (https://en.wikipedia.org/wiki/Alan_Kay) (This timeline date is approximate)

1968
First Windows Style PC Prototype

Douglas Engelbart takes all the technology thus far into consideration and fashions a PC with a mouse, windows, and icons.

1970
Waterfall Emerges – Sort Of

When one reads the infamous Dr. Winston W. Royce paper “Managing The Development of Large Software Systems”, they find something fascinating.  He never mentions “Waterfall” as a term.  In fact he never claims wholeheartedly that the processes and their alternatives with a plethora of steps in the paper will even work in many cases. How did he become the Father of Waterfall? His claims are taken out of context and written about in papers to the point he becomes and enthusiastic proponent of this fiction known as Waterfall.  This is a great case study for anyone who wants to learn how powerful misapplied information in an inappropriate context can look as right as rain, but in fact, completely misrepresent the intent of the source. Furthermore, for about all of human history, society has been inventing processes to get work done with less pain for better or for worse, which points to a progressive process of refinement that brought about Waterfall rather than an intentional invention.  No matter how the “Waterfall” software development life-cycle got it’s name, it is a process concept with many variations that developed over time through a natural drive for process improvement.  This event in history is the only non-event in this timeline.

1976
Apple I – First Assembled PC Sold

Steve Wozniak and Steve Jobs broke from HP to build the first fully assembled PC and in 1977 the Apple II was an even more complete system.

1994
Design Patterns Emerge

The Gang of Four (GOF) who are Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides brought their experiences to bear noticing much needed naming convention for repeatable patterns of object oriented design.  This lead to an industry of creating and experimenting with thousands of design patterns.

2001
Agile Manifesto Attempts a Waterfall Alternative

In response to normative corporate culture that resulted from any number of “Waterfall” methodologies, namely a perception of bureaucracy or the reality of slow progress that many experienced, 17 participants went up in the mountains of Utah and descended like Moses with an alternative approach to project management, hoping for more productivity, less documentation and more working software. What they produced was a less rigid set of guidelines and principles that in practice allowed for extreme flexibility in the interpretation of the manifesto to craft new project management processes.  Less hardened than say, Mosaic law, and most certainly not given from a divine source, the Agile Manifesto has loosely been used for the basis of a myriad of different project management process models.  An important note in relation to domain-driven design is that, many agile based models in practice have left any semblance of a domain model design step off the table. This might perhaps be out of fear that one might accuse a practice of reintroducing Waterfall or because the industry as a whole has lost sight of modeling as a necessity for complex systems development.  Whatever the case, Agile, like Waterfall, is less a quality software design paradigm and more generally a software development lifecycle or project management concept.  These two concepts, Waterfall and Agile, and any number of blends often termed Watergile, are the basis of most project management paradigms or processes used in organizations today.  The jury is out on how much more effective either of these are especially when considering the project types in which these would be applied.

2003
Domain-Driven Design Invented

Eric Evans publishes “Domain-Driven Design: Tackling Complexity in the Heart of Software”, commonly referred to as the “Blue Book”, the book that inspired the industry much further in its ability to model aspects of the real world so the computer could do more of our work more reliably.  ~ From the back of the book: “The software development community widely acknowledges that domain modeling is central to software design. Through domain models, software developers are able to express rich functionality and translate it into a software implementation that truly serves the needs of its users. … This is not a book about specific technologies. It offers readers a systematic approach to domain-driven design, presenting an extensive set of design best practices, experience-based techniques, and fundamental principles that facilitate the development of software projects facing complex domains. Intertwining design and development practice, this book incorporates numerous examples based on actual projects to illustrate the application of domain-driven design to real-world software development.”

2006
“Applying Domain-Driven Design and Patterns: With Examples in C# and .NET”

Jimmy Nilsson publishes “Applying Domain-Driven Design and Patterns: With Examples in C# and .NET”, taking the essence of DDD and applying it specifically to .Net.  His book includes a forward by Fowler and Evans.  ~ From the back of the book: “Patterns, Domain-Driven Design (DDD), and Test-Driven Development (TDD) enable architects and developers to create systems that are powerful, robust, and maintainable. Now, there’s a comprehensive, practical guide to leveraging all these techniques primarily in Microsoft .NET environments, but the discussions are just as useful for Java developers. Drawing on seminal work by Martin Fowler (Patterns of Enterprise Application Architecture) and Eric Evans (Domain-Driven Design), Jimmy Nilsson shows how to create real-world architectures for any .NET application. Nilsson illuminates each principle with clear, well-annotated code examples based on C# 1.1 and 2.0. His examples and discussions will be valuable both to C# developers and those working with other .NET languages and any databases–even with other platforms, such as J2EE.”

2013
“Implementing Domain-Driven Design”

Vaughn Vernon publishes “Implementing Domain-Driven Design” re-energizing the market by helping development teams learn how to take what Evans is teaching and make it work in their world on real projects.  Alberto Brandolini wrote about “Implementing Domain-Driven Design” that “For years, developers struggling to practice Domain-Driven Design have been wishing for more practical help in actually implementing DDD. Vaughn did an excellent job in closing the gap between theory and practice with a complete implementation reference. He paints a vivid picture of what it is like to do DDD in a contemporary project, and provides plenty of practical advice on how to approach and solve typical challenges occurring in a project life cycle.”

2014
“Domain-Driven Design Reference”

Eric Evans distills his “Blue Book” into a quick reference to quickly target the relational, structural and other concepts of domain-driven design.

2015
“Patterns, Principles, and Practices of Domain-Driven Design”

Scott Millett and Nick Tune compile a plethora of thought provoking design ideas to further this journey by publishing “Patterns, Principles, and Practices of Domain-Driven Design”. ~ From the back of the book: “This book distills the ideas and theories of the Domain-Driven Design (DDD) philosophy into a practical playbook that you can leverage to simplify application development for complex problem domains. A focus is placed on the principles and practices of decomposing a complex problem space as well as the implementation patterns and best practices for shaping a maintainable solution space. You will learn how to build effective domain models through the use of tactical patterns and how to retain their integrity by applying the strategic patterns of DDD. Full end-to-end coding examples demonstrate techniques for integrating a decomposed and distributed solution space while coding best practices and patterns advise you on how to architect applications for maintenance and scale.”

2016
First DDD Conference – DDD Europe

DDD Europe annually holds the largest gathering of those interested in domain-driven design often bring nearly two-thousand attendees.  This conference has workshops, keynotes and open-spaces to help thought leaders and learners grapple with ways to use domain-driven design to make complex ideas easier to grasp. This conference is coordinated by Mathias Verraes of Aardling. Aardling is a software consulting and training company focused on the effectiveness of well implemented domain-driven design headquartered in Belgium.

“Domain-Driven Design Distilled”

Vernon explores more of his understanding of this design paradigm in “Domain-Driven Design Distilled” and helps practitioners further grasp each of the critical concepts of this powerful paradigm digging into the meaning and uses of a Bounded Context and how to build a Ubiquitous Language to reduce unnecessary complications with naming of elements. This book is written for a wide audience and for many readers, these critical concepts sparked new ways to view domain modeling to leverage the power of domain-driven design.

2017
First DDD Conference in the United States – Explore DDD

Paul Rayner, seeing the need to promote domain-driven design and related concepts on this side of the pond took the initiative to make it happen and out came Explore DDD. The conference was held each year since except since covid started and is set to pick up again in 2024.  The conference is much like the format of DDD Europe, with a special emphasis on really allowing the open spaces to breed new ideas and help people solve real world problems.

2021
“Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy”

Vlad Khononov fills a knowledge gap in the broader economy of software development by helping people reason about this paradigm from a different direction.  His book, “Learning Domain-Driven Design”, is now one of the most used books to better help new practitioners and even business owners learn why and how to leverage this design focus. Khononov states: “Ultimately, in this book we will discuss not only how to design software, but also how to co-evolve the design with changes in its business context. That crucial aspect of software engineering will help you keep the system’s design “in shape” over time and prevent its degradation into a big ball of mud.”

2023
DDDUnitedStates.com Launched

Approximately 20 years after Eric Evans started this domain-driven design phase of computing history by publishing his landmark book, “Domain-Driven Design”, DDDUnitedStates.com is launched to reflect, promote, celebrate and advance the craft. Articulate Domain LLC sponsors this site with the express purpose to raise awareness of DDD, its essence, applicability and benefits.  DDDUnitedStates.com highlights the meetups, resources, history and more striving to connect people who need DDD with people who provide it to improve software success rates and enhance the lives of those who are connected to those efforts.  Are you ready to join in this historical movement?

The story is just getting good…

DDD in the future will reach more of its potential

Domain-Driven Design (DDD) is not nearing the end of its life, it has just begun to materialize into a respected discipline. One evidence of this is the considerable growth of adoption in Europe and the amount of content, pro and con, related to DDD. These type of cultural advancements can take decades or, in the case of Babbage at the start of the timeline above, a century or more to reach much of their potential. Domain Driven Design United States is here to assist with this future along side all of the practitioners and enthusiasts working to help heal the software industry of less efficient and non-existent design practices that lead to software struggles. Both at the strategic and tactical level, we envision a world that finally dispenses with the natural tendency to assume domain experts need not be involved and somehow design comes from coding. These tendencies lead to bloated software, frequent systems redevelopment, and developer burnout.

The future of software with DDD promises to play a significant role in bringing new and far more successful models of development to life. The question is very much like the quandary that presented procedural programmers of old when object-oriented programming came on the scene and even now as functional programming is challenging the object oriented world. Will choose to innovate? Or, will we continue to defend the status quo that have arguably proven their inefficiencies? Will we learn how to grasp clean, domain-aligned, design capabilities we don’t yet understand to gain the benefits that this paradigm, DDD, offers? How quickly we answer these questions and begin to truly honor the domains we serve, will determine how quickly the benefits of the future will arrive.