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.