Why Domain-Driven Design?
Enterprise applications hold the promise of meeting critical business objectives and delivering real value for users. But these benefits are often diluted by the complexity and costs that come with developing them. Enterprise applications are notoriously hard to develop and difficult to evolve as business needs change, and in the end the costs of developing your own enterprise applications often outweigh the real-world benefits they achieve. As a result, many enterprises turn to off-the-shelf, cookie-cutter applications that, by definition, deliver little to no competitive advantage.
With the emergence of the digital economy, off-the-shelf apps just won’t cut it. Enterprises in all industries are under pressure to use software and applications to deliver new, differentiating digital services to customers. How do you differentiate from the competition if you’re using the same applications? The answer is: you can’t. Every enterprise needs to embrace modern software and application development as a core competency.
In light of this, what steps can architects and developers take to maximize the upside of developing their own enterprise applications while mitigating the downside? Traditional approaches no longer work because they result in exorbitant complexity and costs related to rework, increased risk, and project failure. Fortunately, there is an answer, and it lies with adopting modern design patterns like Domain-Driven Design (DDD).
Domain-Driven Design—Key Concepts
The old adage “measure twice, cut once” is particularly relevant here. DDD puts the focus on designing software that closely aligns with your business processes and evolves with changing business needs. It does this by focusing complex application designs on the core business domain being automated. As such, it engages business domain experts up front to iteratively refine a conceptual model that addresses problems related to their business domains.
Thought leaders and subject matter experts have written extensively about DDD, so in this post I would like to cover the most essential concepts—just enough to give you a good footing in these concepts and to prepare you for delving into the next level of detail. The concepts that follow are nowhere near comprehensive with respect to DDD, but these concepts are indispensable to DDD—a required part of your basic knowledge as you peel back the layers.
What Is A Domain?
A domain is a sphere of knowledge, influence or activity. It is the business area of focus for the application developer. The underlying premise of DDD is that the complexity is in the domain, not in the technology. Frameworks and tools have removed complexity from technology and the big payoff resides in a deeper understanding of the core business domain, which gets to the heart of what is really important and the reason you’re writing the application in the first place. By distilling the core domain, you can focus your resources on areas that are most directly related to the problem you are trying to solve with the new application.
The core domain may be supplemented with supporting domains or generic subdomains. Your energy should be directed at the core domain; while supporting and generic domains are often necessary, these are not where you will differentiate your application, so you may opt for buying off-the-shelf capabilities, using existing libraries or outsourcing these less differentiated areas to other vendors. For example, your application may not be focused on financial capabilities, but may require some aspects of it. This is a generic concept that already exists and can be acquired in the form of pre-existing off-the-shelf software or libraries.
How To Identify The Core Domain
The best way to identify the core domain is to have the application developers work closely with business leaders and business domain experts. As you’ll see, this cross functional collaboration is a recurring theme in DDD.
Application developers can iteratively define and refine the core domain by asking the business domain experts questions like: What makes the system worth writing? Why not just buy if off the shelf? Why not just outsource it? The answers to these questions and others will help you distill the value of the application and provide focus around the essential core domain. Once the core domain is brought into focus, all the supporting and generic domains can also be identified.
The resulting set of domains establishes the business areas that need to be modeled. The creation of these business models is also a collaborative exercise between the domain experts and software practitioners.
What Is A Bounded Context?
For any sizable enterprise application, you will inevitably end up with multiple models that have to interact with each other. These models are representations of smaller problems that collectively address a bigger problem.
Each model can and should be dealt with independently of the others and the introduction of this boundary is what constitutes a bounded context. This isolation is the crux of how DDD addresses complexity—by looking at problems and solutions associated with these bounded contexts as separate from each other. Bounded contexts allow the creation of logically consistent miniature applications, one for each bounded context, containing its own domain, code, and persistence mechanisms.
A bounded context defines the context within which each model is applicable. There is a real boundary around each context. Contexts don’t talk directly to each other. They don’t directly share data or business logic. It is precisely this loose coupling that simplifies the big problem by breaking it up into smaller problems.
The need for these bounded contexts becomes apparent when you consider the range that enterprise applications span. For example, a manufacturer may need its application to span multiple, different business domains—sales, production, shipping, finance, human resources, etc. The typical approach to dealing with such a wide functional range is to look for commonality. DDD, on the other hand, encourages you to resist this urge and look at each bounded context autonomously. This is difficult for many of us who have learned to do things once, reuse and not repeat ourselves, particularly as it relates to data modeling. The DDD way of thinking focuses on each bounded context separately and not the commonality between them.
The Need For An Ubiquitous Language
Within a bounded context, business domain experts and application developers collaborate closely to continually refine and adopt an ubiquitous language. This dictionary of terms is a reflection of the domain primarily from a business perspective. A common language becomes critically important when these stakeholders talk to each other. In fact, the ubiquitous language defines the bounded context, i.e., the bounded context is a boundary within which the ubiquitous language is consistent. The ubiquitous language is explicitly agreed upon, and everybody (domain experts, programmers, business analysts, etc.) adopts this language.
The ubiquitous language must evolve as a progressively richer understanding of the domain and the model are achieved. The terms used must be clearly defined, unambiguous, and consistent. If the ubiquitous language cannot be used to clearly express complex ideas, then you have more work to do.
The terms in the dictionary should be used in ways that make them truly ubiquitous throughout the bounded context. When it’s time to implement the application, you can use the same terms—these terms should permeate the code and be used as names of classes, unit tests, and even as terms that end up in the UI.
Perhaps this discussion has raised a lot of unanswered questions. For example, how do multiple bounded contexts communicate with each other with each one having its own ubiquitous language, domain model, business rules, etc.? The DDD pattern describes this at great length, and this, along with other topics, will be covered in a subsequent blog post.
You can also hear more about these concepts directly from industry experts. On September 14, 2016 at 11am PDT, Pivotal is hosting a webinar featuring Vaughn Vernon, widely regarded as the leading expert in DDD, and Wes Williams, a software designer and architect at Pivotal with extensive experience in DDD.
In this webinar Vaughn and Wes will discuss how DDD and Reactive Programming can simplify the complexities around enterprise application development and how you can use these frameworks to reduce time to market and improve quality. Click here to register.
About the Author
Jagdish Mirani is an enterprise software executive with extensive experience in Product Management and Product Marketing. Currently he is the Principal Product Marketing Manager for Pivotal’s in-memory data grid product called GemFire. Prior to Pivotal, Jagdish spent 10 years at Oracle in their Data Warehousing and Business Intelligence groups. More recently, Jag was at AgilOne, a startup in the predictive marketing cloud space. Prior to AgilOne, Jag was at Business Objects (now part of SAP), Actuate (now part o OpenText), and NetSuite (now part of Oracle). Jag holds a B.S. in Electrical Engineering and Computer Science from Santa Clara University and an MBA from the U.C. Berkeley Haas School of Business.More Content by Jagdish Mirani