[Best of 2022] #76 - Learning Domain-Driven Design - Vladik Khononov

Hey, a quick message, for those of you who are listening to this episode on Spotify, I have a small favor to ask Spotify. Now allows mobile users to rate podcasts, I would really appreciate it. If you can take a quick pass to go to the technique Journal podcast page, and leave your favorite show, your best rating on Spotify. It will help me a lot to get this podcast to reach more people on the platform. Thanks a lot.

Today's clip is from package, you know, episode 76 Six with blood like Conan off the author of learning domain driven design in this clip. Bloody shared why understanding business domain is crucial in software engineering and how DDD can help build the shared understanding between the domain experts and software Engineers. Vlad also explained the importance of dedede's strategic design So I read that particular

preface in the book as well. Your story about starting in this new company and you thought that you will learn a lot of things about software, and the business logic, which apparently was not emphasized and actually bdd actually emphasize these importance of business logic or domain in this particular sense. Why do you think domain is still the key thing in software? Because these days a lot of Technologies, right? So there are plenty abundant Frameworks programming language

cloud. Rubber that is, why do you think business logic is still the tea in this modern era? Yeah, so business logic is hard of software. For reason is the reason suffers being built, you're not building software to demonstrate how fast and scalable your databases or how sexy your user interfaces your billing software for solving a particular business problem.

This problem can be making someone more efficient streamlining, business processes, nowadays, many businesses are built on. On software, that's their business domain. So that's where a business logic steps in. If you've got everything right, except for business logic, you'll get technology demo for computer game looks nice, but you look at it for a few minutes and then you get bored because it's meaningless.

So, you also mentioned in the book that actually DDD brings not just software developers as the important actors in the software development life cycle. But actually also the business domain experts tell us more about this, Business domain experts should be involved in the overall software development life cycle. We are so, that's actually the biggest lie of software engineering and it's to be a

software engineer. You have to write code and I am an introvert to the Bone. After some time, realized, hey, we're not trading called, for the sake of writing code, we are writing code to solve a problem for someone. This, someone they are a domain experts. There are people who have the most knowledge about the business domain that we We're modeling and implemented in

code. So, in order to efficiently, solve that problem, we have to communicate with them, talk with that, we have to be effective in that communication and collaboration with people. So, software engineering is not only about code. That's why interactions with domain experts plays, a key role in implementing software. You have to make sure that you understand the problem, you're solving, that's critical. You cannot provide a software solution without understanding the problem.

First. There is going to be a wrong solution. Always going to be the right solution but for a different problem and both are useless. Yep. And that's a critical point in the book that you mention as well. If you fail to understand the business problem or maybe the problem per se, the user problems or the customer problems, you will eventually write a suboptimal solution, even though your technology might be Advanced the most advanced in the current ERA, but your software is always

suboptimal. What do you mean by this can technology? We actually solve how your software is being written, why? It's always be suboptimal. Yeah. So if we take this name of this methodology domain-driven design, I prefer to expand it a bit and say, business domain driven software design. So we have three components here. First of all, we have business domain that we have to grasp. We have to understand, second, we have software design, that's

what we are building here. And we have that word driven in the middle which means in Mathematical language, slyke sorcerer design equals function of business domain. So if you don't get that business domain, dried and you'll get your own software design. First of all, it's going to affect the logic of your code. As I said, you may be solving the wrong problem, or you may be trying to solve the correct problem, but in an inefficient

ways. Second, as the measurement, design guides us, there are quite a few design decisions that were basing upon that knowledge of business, domains So that strategic design decisions, like what are the coarse-grained components that we are going to use to implement our system? How are they are going to communicate with each other? How we allocate that work to suffer engineering teams? And we have technical design

decisions. Like what design patterns were going to use to implement each components, how we're going to implement its business logic. How we're going to orchestrate the interactions of different parts of a component. It's our internal architecture. Of course we have high-level architecture how components are working with each other and that also has implications both on strategic and tactical level.

Now, if we get that business domain knowledge around, that's a good opportunity to make some wrong decisions. Both strategic and tactical W. So that's, in my opinion, why we have to make sure that we have enough knowledge of the problem domain before we're even trying to design a solution for it. It. And sometimes what I can see, as well as software developers, I mean, we are all clever people.

I, we also sometimes think of imaginary problems or imaginary Solutions. We think that oh, it will be cool. If the most, typical one is something happens in atomic fashion. So, everything is just one transaction, they will be real-time, cool. And people will just see the results as possible, but sometimes business process doesn't work this way. It's okay to have some delay and that's why we have more event-driven architecture asynchronous and things like that.

And this Leads to a lot of things that we know software projects tend to fail traditionally. We all learn about that. Maybe 50% or more of software projects are failing. Do you think By domain-driven Design This crisis can actually be solved? Yeah, I actually believe that. So if we look for reasons why so many software projects fail to look at studies that were conducted on this topic. You'll see that quite a few of

them. If not all of them fail because of communication issues, Shoes, or something related to communication, it can be communication between team members communication between software engineers and domain expert communication issues between management and Engineering teams. The core principle of domain driven design is building a shared understanding between the different stakeholders of the project so that they can speak.

And reason about that suffer system in the same language in DD lingo, it's called a be cutest. Which once we will be able to facilitate communication in the same language without the need for multiple translations, before a knowledge, reaches, its destination, everything will be way more efficient that can solve as a lots of rework, what's of wrong assumptions. And eventually, I believe it will lead to more successful software projects.

And it probably also could help in translating the changes in the business as well. So, let's say these days, everything gets disrupted easily. If you really understand the business domain, and use the same understanding the share understanding, I like what you mentioned, the ubiquitous language and maybe the business process, maybe you can also adapt your software easily.

You can use the same terms, same understanding, even your software, the code classes, maybe the objects are named similarly so you can actually probably adapt to the changes pretty A much easier because the business domains, the business, understanding and software developers understanding basically, are the same, am I right to set? That actually the case. What did it is trying to solve? Yeah, yeah. That's as well. Because everything changes, especially if you're working for

a stirrup Infinity cases. The Stirrup is new, not only that, we are software. Engineers have no idea how to implement that the most efficient way. But Bill's people have no idea how they're going to solve certain problems. That they are focusing on date, knows that. Hey, that's Something that we want to do. How we're going to do it. We're going to iterate. We're going to test him Solutions until find the most optimal one.

And guess what happened? During that time period, everything is going to change that understanding of the business domain is going to evolve, not only, you're going to learn more and more about it. But those business people, those domain experts, they're going to learn as well as the gain more knowledge that has to be reflected in software design decisions. So, Going back to that formula of software, design equals function of business domain.

If that component business domain changes, it has to be reflected in software design. There can be many types of changes starting from may be a more. Efficient way to describe the business, domain better terminology, a better understanding of the business processes, like what you just said about transaction, boundaries for example, what should be strongly consistent? What can be eventually consistent. But also the whole Jesus do making change.

Now, it's not unusual for a company to start with one business goal, and change it along the way, because the previous one wasn't financially viable. For example, software project that was implemented. In the first Reincarnation of the company is not necessarily relevant for the new one because this is the main we change, its sub domains may change. Everything can change, it has to be reflected in software design, failing to react to changes in

business domain, will occur. Technical depth over time and eventually it will lead you to a very big technical debt and a big bowl of mud and typically than Engineers will say, yeah, we need to rewrite the whole thing again. So starting from scratch. That's like the typical have a problem in the software industry. So you mentioned that we have two things in DDD, right? What is called strategic design and also technical design throughout my journey learning about DDD, as well.

I typically started from the technical design. I mean, just to be honest. Everyone here I started with oh I can see repository use case Service Pack then it looks cool and I even started from a framework back. Then it's like spring framework. They have all these term in the framework. So I started from there and learn the Eric Evans books as well.

So that's where probably people started as the first path towards domain driven design but I do along the way as I learn about it. The most important part is actually, the Strategic design. Can you tell us more about strategic design? What it is, it actually about and why it is much more Important that the Tactical design. Yeah. First of all, I fully agree with you.

I think that strategic design is way more important because you can write, pretty successful project while incorporating only strategic design decisions, but if you're focusing only on technical design decisions. Well, that's probably not going to end well. At least in my experience, I wrote a chapter in the book about my story of applying the major redesign in that company. It's similar to what you just said. I read four chapters of the blue

book, and let's get started. Let's model everything as an aggregate. So strategic design. What is it? First of all, strategic design is about creating a shared, understanding between software engineers and business domain experts. It's about cultivating that shared language, shared understanding. Now, to do that, there are a few requirements from that language that you're using in

communication. That's my requirement is Each term should have one and only one meeting people, unlike software, they are so unpredictable, sometimes they can say one thing, but mean something else? Because the context is different, we cannot allow that when taking a software design decisions, we have to make sure that every piece of knowledge is explicit.

So the major InDesign says, hey, when you have such ubiquitous language, that depends on context model, it explicitly in code, defined the context, Which that language applies, its bounded context, that's the name of the pattern bounded context, and that's the first strategic design decision. It ensures that you have a model and compost by the bounded

context, which is clear. Each of its terms has only one meaning now many because of some historical issues and mistakes think that bounded context is necessarily microservice, that's not true abundant context. Is it rather your biggest valid? Monolith because it encompasses a model that has no conflicts in it. You can decompose it further but

that's a different discussion. But the idea is to file those boundaries that ensure that you have a correct model in it without no conflicts or collisions. So, that's your first strategic design decision. You are deciding what you're going to implement, what is the business domain? And what are the core components of your system that you're going to build second assistant? Doesn't build itself for that. We need us software engineers in

any organization. There can be either one team of people or multiple teams of people working on the same project and that again, affects how you design those bounded context because they have to interact with each other. Now, let's say you have two bounded context implemented by two different teams think of two examples. The first case they have a really good collaboration between them, they're like two teams.

But they understand that they're going to succeed or fail together, so they're really trying to care for each other. If there are some integration conflicts, they are going to just go ahead and fix it without making magic drama about it. Now let's fast-forward to same company, lots of money and suddenly they became a huge Enterprise. And again we have two teams working on two different bounded contacts. Now suddenly there is no such good collaboration between the teams.

One team asks to modify the integration interface and now you have drama. Now you have meetings such Etc and that of course, postpones to the release. It negatively affects the progress, etc. Etc. Well, the management design says, hey, that's something you have to take into account. When you are designing, those components have, there are going

to be integrated. So, for example, in the first case, the pattern can be partnership, those teams their Partners, the interested in succeeding together in the In case, one of the customers, suppliers patterns, might be a better choice because they provide that certain level of isolation between the team so that the changes want to propagate across the integration interface and cause all the

drama. So, that's the second strategic design decision that we are making according to both business domain and the structure of our teams going back to our previous discussion, the structure of engineering teams can change as well. Two teams can be in Partnership. Beginning, but a few years later there will be like enemies of each other. That should affect the way those bounded context are integrated with each other. That's an important design decision.

So, it seems that a few things here, if I heard what you mentioned, just now, right? The first thing is actually ubiquitous language. It's like almost every book. I read every resource. I read about domain-driven design, ubiquitous language is the first thing, which also then, translate into multiple things on this context. That's also another important aspect within the context

itself. The ubiquitous language should also translate what you said is without any Collision without any Clash of understanding of a particular term. So let's say a user you've mentioned is in one bounded context. Yeah, it's clear. What is the term used in this bounded context? But in another bounded context it might mean something different. Depending on that contact. And then another thing that you mentioned, the funny story about the integrating between two teams.

I think what I understand is something related to like integration of A bounded context, and what the book says, it's about context map, right? So how do you actually map between two bounded contacts? There are different ways of how you can integrate things. Like are you mentioned partnership customer-supplier conformist and things like that? I hope you enjoyed this short clip from tackling Journal favorite playlist. If you find this episode useful,

please help. Share it with your friends and colleagues who you think would also benefit from listening to this episode. And if you want to listen more from this conversation, please go back and listen to the original full conversation with my guest, stay tuned for the next technology, no episode. And until then goodbye.