On June 11th, we held an online tech meetup on a very trendy topic — Domain-Driven Design (DDD). What is DDD? How does it work? Find the key takeaways from the meetup below.
Our colleagues Oleksandr Demianenko, Full Stack .NET Developer at Daxx, and Vsevolod Istochnikov, DevOps Engineer at Daxx, gave us a great introduction into the fascinating world of domain-driven design.
Let’s start with the definition.
Domain-driven design (DDD) is the concept that the structure and language of your code (class names, class methods, class variables) should match the business domain.
When you develop software, your focus shouldn’t be exclusively on technology in the first place but on business or whatever other activity you’re trying to handle with the software, the domain. It could be any business domain (aviation, railways, banking, e-commerce — you name it). The aim is to develop models of that domain and make software conformed to that.
DDD is a very vast field. We’ll consider just a few of its basic concepts on the ppt slides below.
When we’re talking about DDD, the concept of ubiquitous language inevitably pops up. It’s a language structured around the domain model and used by all team members to connect all the activities of the team with the software (within a bounded context). It’s one of the fundamentals of domain-driven design. It allows the whole system to evolve around one language.
Now let’s take a closer look at the domain and subdomain types.
When it comes to architecture in DDD, it can be displayed like this:
To dive deeper into the topic, watch the speech by Eric Evans at DDD Europe 2019.
Also, the speakers recommended reading the following two books:
- Domain-Driven Design by Eric Evans
- Implementing Domain-Driven Design by Vaughn Vernon
Thanks a lot to our teammates for sharing their knowledge and introducing us to the subject of domain-driven design!
It was very engaging and motivational!