Advancing Enterprise DDD - Working with the Tools We Have

We’ve done our best to do Domain Driven Design with the standard enterprise Java toolset: Java, Spring, Java Persistence API (JPA), and a relational database (RDB). While this has been a very successful stack for us in developing enterprise applications, we’ve encountered problems doing DDD well in this environment. In this series of essays, we will look at some of the difficulties we’ve had, and consider ways to improve our situation. We provide advice for doing DDD with the given toolset. And we look ahead to how we might do DDD better with different tooling - specifically, replacing Java with Scala, and RDB with a document database such as MongoDB.

Domain Driven Design can be an extremely powerful approach for managing software complexity in mid to large sized projects. When we do DDD, we place our primary focus on the domain - our understanding of the problem space and the conceptual requirements of the software and the business. Our domain continuously evolves through close interaction between the engineering team and the domain experts, or our expert users. In order to facilitate communication, we use a ubiquitous language - a common language shared by all the contributors to the project. This continuously evolving domain becomes the centerpiece of our application, and the other parts of our application, such as the persistence layer and the user interface, are subordinate. In other words, our DB, our UI, our planning, and UX, are all expressed in terms of the domain and the ubiquitous language.

So much of our time as engineers is spent focusing on the technology we use. Our daily considerations to technical matters affect and influence our thinking. We attend to other, non-technical tasks of the day with a technical mindset. It naturally bleeds into activities such as analysis, modeling, and design, and sometimes we don’t even realize it. This creates a natural tension with the principles of Domain Driven Design, which ask us to think as much as possible in terms of the domain.

For years, we have had a great toolset for building enterprise software with Java, Spring, JPA, and a relational database (RDB). Java provides a firm object-oriented (OO) foundation for our software, and a plethora of high-quality libraries are freely available. Spring helps us organize our mid to large-sized projects within an enterprise framework. And Hibernate, which later evolved into JPA, provides a powerful interoperability layer between our OO codebase and an RDB. And the RDB has been the mainstay of fast and efficient data persistence for decades.

To be sure, we have successfully built many great systems with this toolset. But we often fail to build systems that follow good DDD practices. There are many reasons for this, including a solid team commitment to do Domain Driven Design. Like doing Agile, to really be successful, we need an influential voice on the team who is consistently advocating for following DDD practices. But it’s also true that our Java/Spring/JPA toolset doesn’t always support our efforts to put the domain first.

In the meantime, technology keeps moving forward, and the set of tools in our toolbox is growing. A wide variety of approaches in data persistence, commonly grouped together as NoSQL, have cropped up to challenge the RDB mindshare. And we are seeing functional/OO hybrid languages (F/OO) such as Scala gain in popularity over the traditional OO approach. These new tools have the potential to make doing Domain Driven Design much easier, if they help us think and speak more frequently in the terms of our ubiquitous language.

In this series of essays, we will look at some of the specific ways that our Java toolset conflicts with our efforts to do DDD. We’ll consider approaches to overcome these difficulties. Some of these techniques are specifically about using JPA well, but in many cases, we can make things easier by drawing on the new NoSQL and F/OO tools in our toolbox.

In the next essay, we will look at the Java EE toolset we are using in more detail, focusing in on JPA/Hibernate in particular. Are these tools in harmony with our efforts to do DDD?