As the code base of a company grows, it becomes more complex. This complexity can lead to different sorts of communication problems capable of affecting both monolith and microservice architectures. In this regard, domain driven design is a tool for enhancing and clearing communication and putting together cohesive software development teams. In this episode, we will learn about domain-driven design, the concepts it encompasses, and how code shapes businesses.
Edited transcription
Vaughn Vernon is a software architect, developer, and prolific author of books about software development. Having started his career in the early 80s, Vaughn is one of the early adopters and promoters of domain-driven design (DDD).
DDD is a software design strategy based on making the code reflect the business or domain logic of the organization. In other words, DDD is meant to build a software product that integrates with user activities by building a domain model.
In software development, domain stands for the activity or interest in which the user uses the program in, e. g. the domain of a restaurant ordering software could be the restaurant, its clients, staff, and dishes. A model, for its part, is a given knowledge structured in a way that is possible to make sense of it to understand or solve a problem, which, in this case, is the domain, that is, the activity in which this software is meant to be used. Models reduce the complexity of the subject by letting us focus exclusively on what will help us deal with a given problem.
Hence, a domain model is an abstraction of a given knowledge made so we can communicate that model in a way so we have a comprehensive view of the problem and its solution that we can use to write code. A domain model represents the concepts, terminology, and relationship between entities of the problem domain.
DDD is a way of creating domain models and, hence, exploring a given model. Domain models transform the domain into a language by structuring the knowledge in a domain of interest, acting as a sketch containing the set of classes of a software project and how these relate to each other, incorporating both system behavior and data. The model acts as a common language (known as ubiquitous language) for teams toward the project they are working on while improving communication between developer teams and domain experts. Plus, they can write code that is understandable by anyone in the project.
Vaughn says that DDD started getting traction thanks to the popularity of two books: Eric Evans’ Domain-Driven Design: Tackling Complexity in the Heart of Software, which Vaughn regards as a classic and go-to bibliography on the subject, and # Applying Domain-Driven Design And Patterns: With Examples in C# and .net by Jimmy Nilsson. The latter succeeded, says Vaughn, since it employed NET C#, which was becoming more prominent at the time the book came out.
Vaughn teaches DDD methodology in workshops of up to 25 people with diverse experience. “Sometimes what you run into is a very senior person and on the other side of the spectrum, a very junior person, and trying to cover that range in a workshop can be very challenging,” he recalls. Regardless of their seniority, Vaughn says that most developers are willing to learn DDD and are very interested in it and its ideas. Still, as of today, Vaughn affirms DDD is not living up to its potential in the industry. He points out that despite what DDD brings to the table, it is practically not taught at universities.
The challenge, says Vaughn, is “convincing people that this is really the way that you have to develop software”. What distinguishes DDD, says Vaughn, is how much it improves communication: “Mel Conway said this back in 1967, Conway’s Law, ‘the communication structure and the quality of communication will be reflected in your system design’. DDD is built around communication.” With DDD, teams become capable of “reflecting their communication and innovative thoughts into software as a language.”
Microservice and monolith architecture in DDD
When choosing between microservices or monolithic applications, Vaughn understands that it is crucial to think in terms of modularity. As he puts it, a microservice is a module that can be very small and communicates with other modules. In the monolith, in turn, the communication between modules, which objects are related to each other, and how they communicate cannot be seen.
It might look as if modularity is not applicable in a monolithic architecture. But it is not the case. In fact, DDD encourages employing modularity in monolith applications. The lack of modularity in monolithic systems can make communication from different parts of the business end up tangled together.
Microservices, for their part, can suffer the same problem. When microservices are in large numbers, they might need more coupling to work, while becoming less independent from each other. This is the opposite of the loose coupling microservices are meant for.
Therefore, Vaughn argues that modularity, in a monolithic or microservice architecture, demands us to “think in terms of ‘if I were to modularize a specific conversation or a specific set of conversations with the business, where would I put those conversations? What module would I put them in?’”
Bounded context
In DDD, the solution to organizing modularity is the concept of bounded context. A bounded context is a boundary within a domain created to apply a particular domain model in it with its own ubiquitous language. Creating this boundary does not mean that bounded contexts are isolated from one another. In turn, according to Vaugh, bounded contexts help to create modules as a “middle ground, probably more toward the small end than the large end, the monolith end.”
By defining bounded contexts, we can start to reduce the monolith to modules and embrace an organized monolith by putting “multiple of those smallish modules into a monolith”. With a set of bounded contexts in a monolith grouped by modularity, “you might even think of it as a business capability or a fine grain business capability that’s in this module.” To Vaughn, it is thanks to packing these modules that “you can actually make sense of this monolith.”
For applying bounded context to microservices, in turn, Vaughn recommends “pulling some of those dozens of different entity types and processors into a bounded context, a single module, and releasing microservices at that module level.” He ensures that by bounded contexts it is possible to “reduce your total microservices from hundreds to maybe a dozen or so”.
This smaller number of microservices is approachable, and even if you end up with a dozen or more microservices.” The best thing is that “if I don’t know the answer to one of those dozen or dozens of areas, I’ll just go to someone else because I know who that team is.”
Employing bounded context, you can either choose a monolithic or microservice architecture or even both. “Maybe the things that go into the monolith don’t change that often, but the things that you decide to use as microservices change more often”, says Vaughn.
Adopt DDD early on
In Vaughn’s experience consulting companies, the best approach to prevent code base poor communication is thinking in terms of modularity from the start. Businesses, when they are just at startup, have a code base large enough to start running. Before their code base becomes more complex, they should figure out how they will scale and “start thinking about the modules that each of these things fit into, where they belong and how they talk to each other”.
According to Vaughn, this does not mean disregarding a monolith architecture right away, but “learning to separate things into different modules.” Hence, the company will be able to figure out boundaries and if they might need to break down their monolith application into microservices later.
The bottom line
Vaughn is currently working on Domo, a tool for event storming, DDD, and other related software development practices.
Vaughn’s product development company Kalele offers different resources for learning more about DDD, such as its blog, podcast, and Youtube channel, as well as the schedule of Vaughn’s public courses and workshops. You can find Vaughn’s books on Informit or Amazon.
You can follow Vaughn on Twitter and visit his website.
