Intro to Domain-Driven Design
IT Tips & Insights: A Softensity Software Engineer takes an in-depth look at domain-driven design.
By Douglas Moura, Software Engineer
Building software is rarely easy. We’ve faced a hard time building it since the beginning. But it should not be like this, right? One very famous approach that is used to help us in the journey is known as Domain-Driven Design.
The software community has considered modeling and designing software a critical topic for at least 40 years. But it was only in 2003 when a man called Eric Evans considered writing a book about the subject. The book is called “Domain-Driven Design: Tackling Complexity in the Heart of Software,” which is known by many as the “bible” of Domain-Driven Design.
What is Domain-Driven Design?
Domain-Driven Design, also known as DDD, is a set of tools that enables you to design a software model that delivers value. The intent of this technique is to align your code with the reality of your problem domain.
Before you can start developing your solution, you must clearly understand the problem, its terminology, what is considered a success from the business point of view and the reasons behind it. And, if you use DDD during the development process it’s highly possible that you develop an even better understanding of problems.
To define Domain-Driven Design we should first discuss the meaning of domain. Domain is the reason this approach exists, the reason the software is being built. For example, why would we build a payment solution? Maybe the solutions in the market do not have all the payment methods we want, and we want to deliver a solution that can accept almost anything. Here it is, our domain: Payment solution with all payment methods available.
The goal of DDD is to make the creation of complex solutions a little bit easier, focusing more on the problem itself than technical details. Of course, we will always have technical details to be aware of, but thinking in terms of domain and technical details apart can make a huge difference while building the solution.
About Design
DDD utilizes strategic and tactical patterns to help us understand the problem domain and create a useful solution to solve the problem.
The strategic pattern is about distilling the problem domain and shape of the application. It’s impossible to write the perfect software, so we need to gather development teams and domain experts to distill the software in smaller pieces. After that, we should discover what’s the core main, which is the reason why we are building the software, and where we should focus more effort and talent.
The tactical pattern is where we create the models, which is the team’s agreement upon how we will structure the solution of the problem domain.
About Communication
Ubiquitous language must be one of the most important concepts of DDD. It states that the language spoken among the team and implemented both by the model and the software should be the same. The benefit of this common language is that when the team is discussing something, the meaning should be the same for all members of the team.
Bounded context is also another important concept. When discussing a huge problem domain, we probably are going to use the same terms for different purposes. For example, we could talk about the client’s concept from the sales or marketing perspective. When we say we are thinking of something in a bounded context, it means that inside this boundary, the terms and concepts discussed have one and only one meaning, but if we consider the same terms and concepts inside another bounded context, they likely have a different meaning.
When To Use Domain-Driven Design
DDD is not a silver bullet. It requires a lot of effort, an iterative development methodology and an engaged team of developers and domain experts. All software projects can benefit from the use of DDD, but you should consider if the effort pays its price. If you’re building simple software, it might not be the best choice, but if you are building extremely complex software, you should consider it.
Considerations
Domain-Driven design is a whole methodology, it promotes a new way of thinking, focused on the domain. It also considers that building software is a team effort that evolves all the time. Consider giving it a try!
About
Hey there! I’m Douglas, a software engineer with more than a decade of experience. Most of my experience comes from the .NET stack, from desktop to web, ranging from small personal projects to huge and complex systems. I’m engaged in delivering the best experience possible to our clients, that’s why I love studying how to do that.