Programmers have to come out of their cubicles, Innovative
software development, doesn't happen with one person in a
cubicle with great ideas, because it's not just even about
phone, anybody been? Like the, it's about what does
the code accomplish and if the quote accomplishes something
Innovative great. Hey everyone.
My name is Henry Surya be Robin. And you're listening to the
tekhelet Juno, the show will be bringing you the greatest
technical leaders practitioners and thought leaders in the
industry to discuss about their Journey ideas and practices that
we all can learn and apply to build a highly performing
technical team and to make an impact in your personal work.
So let's dive into our Journal. Hey everyone.
Welcome to The new episode of the technique journal in 2021
with me Ojos Henry Surya without one.
Thanks for tuning in and spending your time with me
today, listening to this episode after a two-week break.
I'm looking forward to kicking off the show.
Again, in this new year, with a number of amazing upcoming
episodes which are lining up to be released in the next few
weeks. And by the way, Happy New Year
to all of you. And I wish that all of us will
have a marvelous year ahead of us.
And I hope that we will be in a much better.
Better situation in terms of recovering from the pandemic.
If you still remember at the end of 2020 package, you know, ran
the 20th episode giveaway contest.
For those of you who took part in the contest.
Thank you for participating and subscribing to the show's
mailing list. And here are the five lucky
winners of the jetbrains, all products pack personal licenses.
Congratulations to Anna, Daniel Jardin du K and Lynn.
I hope that the LIE Incest will be of great, help for you this
year. Congratulations, again, during
the two-week break. I took the opportunity to
reflect and look back on how the show has been performing.
And I must say that I am extremely happy to see the
listeners growth and the vibrancy of the community on the
social media channels. For those of you who would like
to add on to the vibrancy of the community.
You can find technology, you know, on LinkedIn, Twitter and
Instagram and make sure to follow the show there.
I'd also like to mention that package, you know, is also
available on YouTube. And during the break.
I added a few new playlist on the YouTube channel, especially
for those of you who, like, to consume the podcast content in a
bite-sized manner, make sure to check out those new playlist,
which include each episode short clip, the patron message, and
the tree tekhelet wisdom, that I've always asked to all my
amazing guests at the end of each episode.
Subscribe to the YouTube channel.
And get notified for any new videos that I upload to the
channel this year. I'm also hoping to increase the
number of patrons contributing back to the show, which would
help me tremendously in producing self-sustaining
episodes week after week. Join us as a patron by going to
technology, you know, the dev slash Patron and helped me to
achieve the goals that I'm currently running on the page
for our new episode in 2021. I am sharing my conversation
with On Vernon Vaughn is a leading expert in domain-driven
design and reactive software development.
He is extremely well known for his best-selling D&D books.
Implementing domain-driven design or the red book and
domain-driven design, distilled the green book and he specially
commissioned by Pearson addison-wesley to curate and
edit his very own Vaughn Vernon Signature.
Series. Vaughn is also well known for
his ID, D Workshop. Which he has been running for
the past eight years teaching people how to implement DDD the
right way. He is also the founder of the
open-source feeling, go platform project, a DDD friendly, to set
for the jvm simplifying, reactive event-driven and
microservices architectures. In this episode.
We discussed many things about domain driven design and
event-driven architecture starting from the fundamentals
and some of the advanced aspects of them Vaughn.
And shared many of his insights such as why developers should
learn more about DDD. The most important aspect of
DDD, the benefits of Eda eventual consistency event
storming and event sourcing towards the end.
One also gave a sneak peak about his new book, Strategic
monoliths, and microservices, and why he wrote it.
And make sure to listen to his advice on why developers should
get out of their cubicles to innovate for the business.
I That you will enjoy this great episode.
Please. Consider helping the show in the
smallest possible way by leaving me a rating and review on Apple
podcast and other podcast apps that allow you to do.
So, those ratings and reviews are one of the best ways to get
these podcasts to reach more listeners.
And hopefully the show gets featured on the podcast
platform. I'm also looking forward to
hearing any comments and feedback on the social media, or
you can also directly send to me at Tech lead, you know, The
death / feedback. So let's get the episode started
right after our sponsor message. Are you looking for a new cool
swag Tecla Journal. Now offers you some swags that
you can purchase online. These tracks are printed on
demand based on your preference and will be delivered safely to
you all over the world. We're shipping is available.
Check out all the cool strikes available by visiting
technology, know that deaf / shop, and don't forget to break
yourself. Once you Receive any of those
tracks, welcome everyone to another show of the technology.
You know. Today.
I'm so excited to have with me. One of the foremost spot leaders
in the industry. His name is Vaughn Vernon.
He is well, known for the DDD workshops.
One of the thought leaders about domain driven design, PS,
written a few books on dvd. One, is the implementing
domain-driven design and the other one is domain-driven,
design distilled. And he's also well known for his
Workshop, which is called idd. D Workshop, which has around for
a number of years. And he also set up a company
called feeling go which is also doing things around Edd and
reactive patterns and things like that.
So, welcome everyone to the show.
I'm so excited to have the conversation with you today.
Thank you for inviting. You Lads people.
So one. I know you have a very long
illustrious career Journey, or maybe for the audience here.
Can you share some of your highlights and turning points in
your career? Sure.
It's funny that you say in long and illustrious.
I would say lat Illustrious. Well, I think I learned a lot
along the way I have done some very nice work.
But I think everyone will consider the row that they've
been on a bit bumpy, maybe more than not.
So I'll tell you my experience. I started in the industry
working at an insurance Clearinghouse company, which was
basically the investors were 11 largest insurance companies in
the US. I can't even remember all of
them. I think Edna was one of the main
one. Ones that was very involved.
So the idea was that whenever someone checked into the
hospital, whether it was emergency or regular check-in,
they would have to later fill in insurance forms.
And it took a long time for them to get data sort of core domain
behind this insurance. Very house was to setup software
that ran on the IBM PC have hospitals.
And whenever patient was admitted, they would basically
start filling out their insurance forms, right?
Then. Of data entry and it's doubled
as also a record for the hospital and then those claims
would be submitted, eventually, whatever.
All the treatment was identify. They would be submitted to a
central processing system validated and then reformatted
into the actual Target insurance company like Aetna, like one of
these other than surance companies and they would be
submitted electronically to the insurance companies.
Now being that I started working there in 1983, almost was T at
that stuff, way back then, before there was a name, he to
be and a lot of integration so forth.
But what I ended up doing was the software that ended up in
the hospital's was initially implemented, using Microsoft
COBOL on the TC and not sure what ever happened to that.
But the COBOL code and executable format took up ten.
This guess this gets at the time.
I think word, I guess 256k or something like that.
And so it was distributed across 10 to scats and Time that a new
module needed to use in the program.
The user would be told soochow, whatever to whatever else ended
up being problematic. Because there was a lot of
Shifting, one of the scats and then there was another discount
for the data sometimes. Literally.
I have a hard time, actually, remembering like, I want to say
Meg, but I know it's not make its K.
And then, when I say can, I was like, I just say to myself.
Wow, that was really, really not much memory, but I was working
at the time and I was like, that's what you had feel.
It's so this is what the environment I was working in.
Well, I read an article invite magazine.
It was this very influential article.
It was on the C programming language.
And I think it was 1983 and for somewhere.
I think it was 83. I went to the VP of engineering
and I said, why aren't we using C instead of kobol?
I'd say we could reduce the program code. 212 scalp.
What was my clay early? It was like a total swag, but I
said, I think we can do it and I did some calculations.
Relations just based on the article that I read, and what I
thought the sort of idea behind the code that was actually there
in Cobol. And what I thought it would
maybe look like in C. Although I didn't know see at
all. But just reading and getting
this excitement over the language proposed this and the
VP was like, you think you could do that.
I mean, these are guys that worked at EDS.
I don't know if, you know, he dies, but he dies out time was
like, if you had been in the military, you got a job.
Looking for Ross Perot and he made a future for you.
And so all these guys were mostly ex-military of some kind.
And so, they were very strict, very demanding, very light blue
suits, with Pinstripes and white shirts, and the red and blue
ties. And they totally looked like,
IBM or Executives off the court, actually anybody at that time,
so I had to wear a suit to work and that was where it was.
So that's how I started my career.
And I thought kind of bent in this very small amounts of code,
very tight code had to work efficiently.
That just became part of me for a long time.
I know later on, I heard this thing that supposedly Donald
knuth said, premature optimization is the root of all
evil, but the way I found out that that was being interpreted
is never optimize anything. Don't care about anything.
We've got big fast computers, a memory is free.
Disk has free compute cycles and everything is free and it just
really bothered me. And so what happened is in a lot
of occasions, I would go in as a consultant.
And and something wouldn't be performing well, and I would say
well, but look, you're not breaking out of this move after
you found something or why aren't you using a binary
search? And so just some of these really
fundamental things that you learned just by reading the K,
NR c-- book or to hand in which equals the fan of binary search
in there. Something you just learned these
things and your mindset was units and see is small tight
fast code. And so I was never really
bothered by people who wanted to Ignore any sort of optimizations
because they thought they didn't need to pay attention to
Quality. And that way I just did it.
Anyway is just a natural find out if I didn't spend any time
on, it is just made sense to me like that.
Okay, so I can use a binary search and I didn't got this
function or method or whatever in a library and I could just
use that. And hey, what?
I don't even have to write my own binary search anymore.
That's just how I learned to think.
And so it's always really bothered me like when I Run into
things these days. I mean, all due respect to these
companies that have created these very, very popular
Frameworks and so forth, but when I learned that screen boot
is something like, 3, GB, just to be 32 gigabytes of RAM and
the lingo is 200 MB startup. It's not like, I'm trying
necessarily going out of my way to make Vlingo small.
It's just what happens. So, I worked in Unix and see
early on, I met a guy. I'd had written some books about
Ramming, he had been a bell Labs employee, and he offered me an
opportunity to write it co-author of a book with them,
because I knew Unix system internals.
This was for, actually the OS two, operating system.
And at the time, we didn't even know what the name would be, but
it ended up being called os/2. At the time.
We saw it is called 286 Das. Which was the process here at
the time that could support protected mode, execution.
So you couldn't address could reference something outside of
your dress face. Otherwise, That was protection
fault. So that was just a lot of my
early days. I would say I was doing that
kind of work quite a bit for probably at least the first 10
years or so of my career. And then I was introduced to
Small Talk, actually probably yelling seven years, and I
wanted to small talk and this is just like this leap mind-bending
experience where I was also programming in C++, but C++ was
mirrored at the time. It was no compiler available.
It was only this thing called seafront, which was Translators,
it would read and parse C++ code and then generate C.
And you have a c compiler to compile that and debugging was
just horrendous because name mangling always, you know, you
couldn't recognize that build, you were working in.
It wasn't until I think really late 80s that a few companies
started coming out with C++, actual compilers, and I think
maybe Borland. And there was another little
company called Data light and probably poems or Tech.
So we started to get like, some real C plus plus programming in
there. But at the same time, learning
small, talk and being introduced to that was just mind-blowing.
It was like, I was talking earlier today to Dave Thomas
Small, Talk, Dave. And we're talking small talk.
And I told him that when I learned small talk, I saw those
some manual or some document. I was reading about small talk
said, this is the small talk language and it was one length.
It explain the entire language in one line code, and it just
blew my mind because they'll take there were many, if any
keywords. I don't remember everything.
Was an object. Well, it took me like a lot of
code just to experiment with small talk and I think within
two weeks, I will, okay, I get it.
Now. I understand why this is the
whole language. But until you get over that
hurdle where there are no key words, there are no everything.
Well, there is a keyword called primitive, but that isn't used
in the small talk code. That is a language construct,
that you have to write like a ski binding for something.
If you You can't actually implement it in small talk.
Or if you need to integrate with some Library Outsider database,
then use primitive to make a method invoked.
Well, you sent the message to some object and that dispatch to
A Primitive method and that primitive method is where you
called actually like a dll or something outside.
So that was one key quoted. But yeah, so that was like the
beginning and then I got into Java when it was pretty clear,
that small talk wasn't going to survive at least in my way.
All because they weren't machines, that could run small
talk really? Well, it wasn't much memory and
small talk unless you had some special tools like and small
talk, which was Dave Thomas his company.
He couldn't, it took a lot of memory to run those but the pure
programming experience and just the pace that you could write
code was just incredible. I mean it was 21 so I could out
code. 20 simplest plus program has no problem.
It was no context. We was no questions.
Asked. So you could just do that
anyway, so that's where I've been, thanks for sharing that.
I mean, it's really, really great to hear that history like
long time. Back even 1983 us.
Like I may not be there yet and I couldn't even imagine like one
diskette is around 256 KB like what you mentioned.
It's really, really tiny. So one you are well known about
domain driven design. I myself, I won't consider
myself an expert on it. I read the book the initial book
by Eric Evans the Book. He was quite difficult to read a
say is very thick as well. And you come up with another
version of that domain driven design book, which is much
easier to digest and I really appreciate that.
And even you come up with another book for the distilled
version, which is even smaller and thinner which condense all
the essence of DVD, but for all our audience here who may not be
familiar with domain-driven design, would you be able to
explain what is actually a DDD? Probably, our exploring.
Will you do differently today? When I do it 10 years ago?
But you could start with saying d d d is, you know, ubiquitous
language in a battle that context and right away, when you
understand what a battle context is that it's the sort of
relatively small boundary where you program code is application
code, is within this boundary. All of them, 100 percent of a
single application, or if you want to see a service it's
within their and then you say, wait a minute, but the word
ubiquitous means everywhere throughout permeating.
And then you say, how can that be?
There's this boundary. Well, it's because the
ubiquitous language is ubiquitous within that boundary
and the team lives within that boundary and the code links
within that boundary and all conversations that you have
about the model. All learning that you have about
what's in this context in the model in this context.
That is why it's ridiculous. It is ubiquitous completely
permeates everything within the context including conversations
that you have those people. And that's the thing is all the
learning. With everything that you're
doing, you're starting to speak a language and you're starting
to make a language and then when you write the code to implement
this language, you are making the code, look as close as
possible to the human conversations that you have.
And the human conversations are between not just developers and
you don't just have like a business analyst coming over and
handing. You these use cases your
specification documents and say code it up.
Looks like we're really having conversations with the exact
people who are Very knowledgeable about the area of
expertise that working. And so, they're called domain
exclusive. I just like to see business
experts, as sometimes the word domain is just not well
understood. So, I just say business experts
within that area, likes fruit, each.
I think it's good to clarify that the word domain, we look at
an English dictionary and look up the word domains.
I think there are at least three definitions.
That's mostly about land ownership or Kingdom or a domain
of a king. But the fourth entry is what
actually really applies most to be me.
And that is a spear of knowledge.
That definition is sphere of knowledge.
Well, once you have the sphere of knowledge, then you do own,
this kind of domain land, whatever you want to think of
it. As you cut out this area of
expertise, and you have ownership of it is yours and you
make it what it is and we make it better.
But it's all driven by that sphere of knowledge that you
continue to develop. So it's all about conversation.
Learning and then improving the code as you can imagine doing
this very well is more expensive than not doing that.
And so you don't want to invest that way everywhere.
You're not going to have that level of conversation and
iteration some things that just aren't that important.
So, you buy what you can, and what you buy is generally called
a generic subdomain. What you're developing on the
other end, when I described previously is a core domain and
then in between that you have something called a supporting
sub domain and the supporting sub domain is something probably
can't buy almost never, but you also don't want to invest a lot
of it. You can't create the core domain
without having this sort of Helper, but you also don't want
to mix this code in with the poor because it's not the same
model and so you separate all these models.
And so you have this core domain, of course, sub domain.
So, if there's a domain that you're working in as, in a
problem space, it has a solution, then you have various
sub domains within that on. Subdomains roughly map to our
contacts. That's quite a DDT.
Those are the kind of strategic patterns and then strategically,
you're looking to. Okay.
I've got all these boundaries Out, download contacts out
there, whether its core supporting generic.
How do we integrate all those and then use something called
context mapping to map between basically the languages and
sphere of knowledge in various places and integrate.
So they call it this over there and it means that there we need
little parts of that. What do we call it here?
What is it to us? Is it the same name?
But a different definition and that's where a bit of a tricky
part comes in, but you just have to take your best shot at it and
see how it goes. And then, of course, you can
Factor if you don't quite get it right.
When I'm listening to you. I'm interested.
When you say that, it's not for everything.
You probably doing it right? It's very expensive, but can you
explain, why is it expensive to do it right?
Versus example, common programming?
Well, it's expensive because you are really experimenting and
having a lot of conversations and you're bringing business
experts into being side, by side with you at certain times, or
you go to them. And so, you're taking their
time. There are certain points in the
project where they have to be involved for several hours at a
time. And then you're not going to be,
right. I don't know how many times
I've, you know, you draw something on the Whiteboard or
you do events, whatever it is that you're doing.
And then you start coding and I mean, you're not voting for 5 or
10 minutes and say, wait a minute.
We didn't think of this and then you go back and while you have
to have more conversations, it just takes more time and you're
using probably the people that are working on.
This are some of the most experienced and skilled.
I remember one meeting I was sitting in with a client and
we're in this meeting and one guy actually, one of the lead
says, it's just names. We can name it anything.
It's just names like and I just that's when you get a twitch in
your eye or Your shoulder or something and that can do like,
you know, this is exactly the opposite.
No, it really does matter. Well, maybe it doesn't matter in
that generic police who, maybe not even so much on the
supporting place, but in the core it absolutely Valves.
And so it takes time to think of those things and experiment with
them and decide is this good? Or is it good enough now?
I think if you look back at agile in general and X key,
you'll see a lot of the Box behind DVD forming at that point
and this Is where, like XP said, expert always available or
customer always loyal customer expert were interchangeable
terms, although they did say customer, but even then they
said, you don't use a proxy customer.
You need the real expert. So all this goes back to that
point. Well, I can't say that.
Absolutely, it did because I wasn't there with Eric Lee
worked on those, but you ask them use very much influenced by
X key and I think maybe even work.
Some of those generally XP projects.
Yeah. So in the first place, knowing
about this, it's probably expensive to do it, right?
Involving. A lot of people.
Why is it important for programmers to know about this
technique and know when to implement it?
Why is it so important to nail about DDD?
Because this is where Innovation occurs.
If you go back to the days of Thomas, Edison Thomas, Edison
said, some people say that I failed six thousand times.
He said I didn't fail 6,000 times.
I just found out six thousand ways.
That didn't work. And then 6001 did, it wasn't
just Thomas, Edison doing that. He had a whole Army of, I think
he had a thousand scientists who were working with him, and they
ran all kinds of experiments. And this was on the light bulb.
I think if you just look up that history.
And so yeah, that was expensive, right?
I mean, how long does it take a thousand scientists to run, six
thousand experiments that don't work.
And how long do the experiments last house?
Does it take to set up the experiment?
What kind of resources do you need to make this work?
Well, finally he got a light bulb that didn't burn out as
quickly as the light bulbs that were in Street lamps in the
early days that would burn out rather quickly.
Now, he had a fill-in them that lasted a long time, narratively
in the end, the experiments paid off and Innovative.
So this is what I'm talking about is programmers.
If they really want to have a strategic impact on the
business, then they will. Will be involved with business
experts and find where investment needs to be made in
Italy, you know, mating, no one. These days is really creating.
Maybe a few people are creating the better light bulb with a
filament that doesn't burn out quickly.
Elon Musk is doing a lot with rockets with spaceships and
because, hey, Erie uses them and take off a little.
And so, there's an innovation. But is the way that he
calculates trajectory and path and so forth.
The completely unique from the way NASA or whoever launch
rockets before, probably not, probably very similar, but
that's not as core domain. The core domain is launching
that baby and bringing it back and not throwing away.
Millions of dollars every time watching box, the poor donating.
So there's the Innovation. And so, that's the thing is
right now, in Space X. I don't know.
I'm just talking because I don't know a lot about that project,
but just imagine that the rocket itself is supporting.
I mean, they Need something. And the fuel is generic, right?
Any Lego by the fuel somewhere and they'd buy some components
and things. They're generic, but the core is
okay. We need some way to not destroy
the rocket and this patch, a bunch of it into oceans around
the globe as its flying and bring it all back and be able to
reuse it. And that's the portal name.
There's the irradiation. So, and I read about DDD a lot
of things seem to be closely tied with object-oriented
programming. Candy DD also be applied to
functional programming, or should we well, yeah, I think
you would say is that can functional programming be
applied to a core domain. Absolutely.
Right fact, we'll talk about a little bit, our new book
discusses that a bit and we'll have even more functional,
programming information later. So, you mentioned a number of
things that will be good. This language bounded, contacts
codomain, generics domain, and things like that.
What do you think are some of the basic most important
Concepts that people? Both should get in order to
understand DDD programmers, have to come out of their cubicles.
I mean, that's funny because nobody's in humans these days.
I think maybe a few that no one's going to offices or maybe
a few people are, but the point is innovative software
development, doesn't happen with one person in a cubicle with
great ideas. And you just keeps bringing them
pizza or Ramen, or clever everyday, and noodles, or
whatever, and they just keep eating and turning out this
incredible code, because it's not just even About fold,
anybody can like those. It's about what does the code
accomplish. And if the quote accomplishes
something Innovative great, but there aren't too many single
individuals. Even if they're great coders.
There are too many single individual programmers who are
just off the top of their head, or even after thinking for a
long time, really Innovative about business things.
And so we have that sort of action symbiotic.
Need to be engaged with the business and The Business. -
with developers because look, Marc Andreessen, said ages ago,
internet time in ages abilities, been nine or ten years now and
said software is eating the world if software is eating the
world and it is even more. So now than it was before you
better learn how to innovate. There's another quote from
Forbes Magazine its online. Every company is now a soffit
that me, if you aren't there, if you'd still consider software a
cost center in your corporation, and if that mentality, linger,
Is for very much longer, you're history.
I mean, there will be these companies that are so huge.
You think they can't fail. Well, they're dying, but they're
dying at 200 million dollars a year and they don't see because
they still make billions and they're like, wait a minute.
So what and all of a sudden within three years or something,
that's a billion. Now, what's going on?
Well, it's because you still have people pushing papers
around and the stuff. Okay, take all those people.
Who've I'm pushing pink Bruce for decades and make them
business. Experts.
They know this stuff. So it's not like you just fire
them. It's not like you go.
Oh, well, we're going to digitally transform and
therefore these people are useless to us.
No, they're not. They're experts at this.
We simply need to know how to make it work with software and
in a leg. Well, then it's interesting that
you mentioned something that is non-technical to explain for
developers to understand. So, getting out of the cubicles
having conversations with People, the domain experts,
especially in an innovate with them.
Because one of these days software is going to be really,
really critical for every every company in the world.
For those people. Who are new to Dee Dee Dee.
How can they start actually? Well, I've got two books.
I would suggest re domain-driven design distilled, first, get
some ideas and then use implementing domain driven
design. Actually, my first book as a
deep dive into each of the topics and more, even that you
read about in the still. And Then, use that red book.
Implementing domain driven design as a reference.
And of course, you always want to get Eric's book.
It is the definition but a lot of people need a sort of
stepping stone or something to get from what is d d d.
And how do we use it in 20, let me know read what was on Eric's
mindfully the five years. He was writing his book and his
experience and we'll see that then and it will make sense.
I provide trainings and so forth, but thing is you just
Have to start somewhere. You have to understand that
again d, d. D is not about coding.
It is, but it's not initially about coding.
And so when a lot of developers want to do is they see the
Tactical tools and they're like, oh cool.
I need to use Aggregates because if I use Aggregates that I'm
using to be. Well, not necessarily.
I mean, you can use the pattern and not even get anywhere near
the value that you get by having conversations with business
people about please. How do you even know you need an
aggregate in the This case then you shouldn't use an adjective
for him. But you all know until you have
the conversations is this thing? What we are talking about, does
it have unique identity and being absolutely need this
transactional scope around this small body of data and
operations. That's when you decide that you
need to use an Aggregate. And so you have to really
understand the Strategic modeling tools first, but those
won't do you much good at all. Unless you're having
conversations with business, experts.
And of course, people are going to say Yeah, but who are the
domain experts in our business? Well, I don't know.
You don't hire people with the title domain expert.
As far as I know. There's probably never been a
classified ad anywhere in Monster or, you know, hubby's
recruiting places that say like domain expert form of such and
such a couple that doesn't happen.
So it's someone he is going to carry a vision based on strategy
and then it's not just about listening to this person tell
you, okay, this needs to be the swing because they probably
won't actually know that. That you have to have
conversations. Another thing that is also quite
related to domain. Driven design is actually even
driven architecture because you have the domain event that comes
up from the modeling exercise and things like that.
First of all, maybe you can explain.
What is event-driven architecture?
Even driven design kind of thing.
Well, event-driven architecture involves events at ourselves to
happiest, but you have a number of services.
Let's say, or applications within a whole system.
And each of those applications is Hitting events that have some
meaning to the overall system or in some services or other
applications within the system. And when you eat those events,
that is the driven part, that's where we are driving.
Those events toward some other services or applications in the
system and they're going to react to those.
And so really reacting to events is what the other systems do.
And when they react it's a matter of okay, when I see this
domain event about just document created or documents edited or
anything like that. What does that mean over here in
this other application? So when you see that event, you
react to it and that is event driven and it's an architecture
because it's not just events within a single service or
application. It is events that are happening
in several of those if not all of them.
And everybody is reacting to those in different ways and you
may even react to you own events, but that is where the
events. Driving what happens next.
So, think of everything in an event-driven architecture, but
everything related to the event driven part of it, as passive.
They aren't doing anything. Until they see any event that
has a meaning to. And so you're probably using a
message bus and some sort of messaging messaging, middleware
or Cloud messaging, whatever Kafka everybody wants to talk
about possible. You know, it's just whatever you
need to get events distribute. No one good.
Design technique is when you receive an event in an
event-driven architecture is you don't consume that event deeply
internally into your model because that creates a very
strong coupling between whoever committed that event and
published that event to you. And now whenever that evoke
changes, what does that do to your model?
So instead what you typically want to do is say at the very
boundary where that event is received you want to Translate
that event into a command that internally means something to
you. So your model knows about, okay,
if I tell it to do this command to execute this command, all it
has to know about is its own language and the command was
part of its ubiquitous language. So this is where ETA and EDD
will together right now. Saying, okay.
We don't want our model to be a conformist to the other model,
because if it was a good for most right now, it maybe you'd
seen that pattern. In in the MV.
What's a conformist actually? Sometimes it can foremost is the
best thing you can do, but try not to if you can avoid it, if
it's not the best thing to do, don't accept could foremost as
oh, yeah. Well, we're conforming to all
their events and now you have 10 services or hopefully not 50 and
you're just reacting to 50 different things at all, 50 of
those other services or application start changing their
events. What does that do to you?
So having that little translation layer in between
your model? And the Eda part of it.
And then part of it was quite important.
Is it fair for me to understand that when you implement even
driven architecture? Basically, you make your system
more adaptive to change more flexible, or is there other
benefits that come out of the Eda?
If you do what, I just described and creating commands from the
events that does help with the pup way, but there is still the
fact that you now depend on even at the boundary, even an
incoming request or mess. Serge Livery, you have a bit of
coupling there. And so, you're going to have to
take on responsibility that if that event changes in some way,
definition or just goes away and is replaced by another one.
You're going to have to do something about that.
So there is that to deal with but it's not as bad as accepting
it. Clear into the middle of your
model. The other thing is because
you're using messaging to deliver these events.
There is a Time coupling. You're not like something
saying, let me query something over on.
At service and see what it tells me.
And then, if it doesn't happen in time, I'll tell him L.
And maybe I have to like bail something.
Clear, back to the user. Instead.
Like I said, your passive and you're reacting to what you told
at any given time and that latency is actually good.
Because now, instead of making all your rest request for all
your art, can see request say, oh, if I don't get an answer
within 5 Seconds, something is broken.
Well, I mean, how many times in a day there's something takes.
Six seconds instead of 3 or 7 Seconds instead of five.
And so you put this arbitrary time out on your rest client,
right? You just say arbitrarily.
Oh, well, it's put a 5 Second timeout because that's our SLA 5
seconds or even 10 seconds or whatever.
Instead. You just say, oh, well, it's
going to happen. And what's our worst case
scenario? If we didn't know about the
outcome of this within a minute. Would that be too long and
oftentimes when you talk to business experts now say no.
I mean nothing. The take half an hour and it
would be no problem at all or even tomorrow would be okay, but
what happens with the developers, they'll just go home
and we need performance. So we're going to put a Timeout
on this and we'll just start failing transactions left and
right. We don't hear something within
five seconds because five seconds, that's forever.
So there is that Advantage with Eda.
The other thing is an important part about that is it's related,
but also a little bit different. Is you do have latency at
various times in the network. You will occasionally have
Network partitions that occur and things like that.
And so having this sort of notion of it.
We're just going to find out at some future time that there was
a reaction to this. Then you are actually embracing
latency. You're embracing the network.
You don't even care. Really.
If there is latency unless it's too much latency like really
really too much latency, but that's not a programmers
decision. That's not a software developers
decision. Too much latency is the decision
of the business and you subtract half.
That's why again conversations. So you ask the business.
How long is too long? Then?
You can create something that checks.
Okay, this event went out at such and such a time or this
command came in at such and such a time and we should be able to
close the loop on this within two hours, but we don't roll
back any transactions. We just make it a business part
of the business process and we say, oh well, okay, that's find
out somebody. He needs to know that it timed
out. Does it mean that we need to
cancel? Making that new ship?
Okay, let's cancel that whole ship project.
That thing that's going to cost two hundred million dollars.
Bill. Let's just cancel it because
something timed out after two hours.
No, I you deal with it in a logical business way.
You tell someone but we didn't hear about this.
Maybe something didn't go right on it.
Was it just the technical failures their way to get that
back on track by clearing a living out of the Dead.
Letter to some. But you're now saying, I mean,
it's not the end of the world. Before we had computers.
We've dealt with stuff like this all the time.
There may not be many people. That remember those days with
pending on the domain, the business that you're working in.
They probably do probably still are a lot of them dealing with
those things. It's interesting, listening to
you talking about this time, the coupling, and all these latency.
So I think it's really tightly related to eventual consistency
pattern. So do you think that most of the
things should be Mounted using eventual consistency way, I
could hearing what you're saying, just now, all you should
confirm with the business. What is actually needed for
Atomic transaction? And while the rest of it, if the
base is confirmed. Yeah, we don't need straight
away. Maybe we can use eventual
consistency. Yeah, exactly.
What we serve. And the thing is, if to let's
say entities are dependent on some change, like one entity in
one context, has a change made to it and another entity in
another context needs a compensating.
Change for that or reactive change based on the other change
that happened. The only really practical way
that you can do that is through eventual consistency.
It doesn't mean that you can never ever use Global
transactions. But as soon as you introduce a
global transaction, just everybody's going to see
everything as a global transaction.
So, I just think most businesses are going to say.
It really, doesn't matter if that takes five seconds or five
hours. I'm not saying that's true in
every case. Case.
But I'm just saying, I think you would be surprised and I have
these conversations relatively regularly, and I asked those
questions. They're like, yeah, it doesn't
matter. It's like not a problem.
The only time that it matters is when the user needs to look at
this over here. And that doesn't seem like
anything's happened to it yet and five or ten seconds have
passed. But in normal situations five or
ten seconds is plenty of time for that compensation.
To of the third that consistency update to have occurred, you
know. Users even to make a gesture
after this, one thing happened, if they are going to actually
drive the reason for viewing, the data from another context.
It may take them that much time, just to make their own gesture
to Anna. And then a way around that is
instead of making the user drive that you simply make the UI
reactive to web sockets or server sent events and whatever
something that is driven to the browser or the UI in any general
way. That says look, The user is just
going to be told when ever this is ready.
We will show it to you and so they're never taught to be
concerned about that. Now.
I think one of the thing why Global transaction is all over
the place, I think in my opinion is that developers like to do it
in a fast way, right? Because Global transaction.
Normally, there's a library that handles out of the box for you.
You just put everything in one, maybe a scope or boundary.
Then the librarian handle out of the box for you while doing
eventual consistency involves a lot of effort, especially
resolving conflicts. And things like that.
So how do you think we should Implement eventual consistency?
The right way? Interesting.
It's like almost every day. You have a conversation with
someone that kind of influences the way you think.
And today I have this conversation with Dave Thomas.
Like I said, one of the things that he said is a lot of
developers can't deal with some of the ways that the V wants to
deal with this eventual consistency.
So for example, implementing sagas with process managers, May
not be the best thing for any given the literal.
Well, I'm going to have a couple beep tithe workshops of January
where I teach that very very thorough.
But if you're not ready to deal with process managers, it could
well be that you really don't need to create a song error
process manager and even though as much as you may really
relish, the idea of doing this kind of work is going to make
you a cool software developer doing it.
Maybe choreography will work fine.
And so you will just react to events that show.
Up. It was long as the process isn't
super complex than that. Is the really correct way to do
it and it's simpler. Now, when something goes wrong
with choreography, it's more difficult.
Potentially to figure out where something went wrong.
But if you only have one or two places where something could go
wrong, it's not much of a challenge.
And so as soon as you cross, that threshold with things where
you just ask yourself, okay, if something went wrong here, like
how difficult would it be to figure out what went wrong?
And that's where process manager or that orchestrated in contrast
with choreography. You can go to that orchestrator
at any time and safe for this thing, this process that began
where did it gets stopped, where it's something not work and it
can tell you right away. Well, I've seen these things
happen, but I haven't seen this and probably even you can teach
the process manager, write code. That makes this work that says,
if you don't see this within a certain timeframe, tell someone
Something didn't go right wide. It could be technology went bad
or it could be that someone has a bug in the code or it could
just be that. What said someone's workflow and
they didn't approve it that and so a person needs to read this
email or some kind of notification that says, oh you
have to approve this and they click, they read it but the
button and maybe that's all you just need to go make a phone
call and say a did you receive this?
And if you did, would you please approve it?
And I don't think that normally, when you start with d, d d,
right? It is Is one good exercise to do
an event storming exercise in which again, like what you said,
conversation is one of the most important thing in DDD where you
gather people from the, it definitely, from the business
side, maybe some other people that are involved in the whole
domain to do this event storming.
So what is event storming and we'll, how does it play an
important role in coming up with a good DDD?
So, you like storming is an activity in lightweight modeling
and there are two levels. Rules of you got storming lot.
See the first level. They can start with is called
Big Picture modeling. So this is where you're trying
to understand the process the overall process through an
entire system as it relates to your current or don't lie.
And so you're using sticky notes of certain colors.
And each of the colors represent a certain kind of thing within
the model and the primary one is orange and orange represents
events. Not just going to talk about the
standard colors that have been chosen for sticky though.
Oats as this traditional or I hate to call it standard, but
point is that it's what people are taught to use.
Sometimes you can't find those colors of sticky notes, physical
ones, and packages. And if that's the case, you
could change them up according to what you do have.
But I'm just going to talk about standard look.
So orange colors are for events. So you write the name of an
event that happens in. This is primarily what working
with an event storming and you stick that sticky note on a
modeling surface. Is just the sort of limited
height may be 1 meter high but maybe 10 meters.
Y or 15 meters wide and you have this modeling space and every
single sticky note. That's put up there is put up
their relative to the time that it occurs.
And so you may actually start in your big picture modeling in the
middle of your timeline. And you might say, well we don't
really know what happens first way over here to the left, but
we do know what happens here. And so let's start.
Working from here and maybe by getting some events up there
that we do understand will start to understand what happens
before. That one will start to
understand what happens after it.
And so it's a discovery tool and then you use other colors of
stickies to represent other things.
That are pertinent to this model.
For example, you can use a purple sticky, purplish sticky
that represents policies and a policy is basically roughly
speaking. It's a set of some business rule
that says, if this event Happens.
This should be done after it or even for this event to occur.
These constraints have to be fulfilled for that to happen.
So the sort of business rules and they just think of a
business rule if you were running a company that provides
service in gardening. So you have a service in
gardening and you normally want to do most of the gardening work
for your clients during a week, probably certain times of the
year and even certain time frames when you don't want to be
out. And Hot sun, but you do it for
some extra money, or we normally don't want to work after 5 p.m.
Or 1700 hours, but we will, for some extra money.
And so you have these policies that say, okay, if you want to
engage us at six pm 1800 hours, and we still have daylight to do
your gardening, we can do that, but it's going to cost one and a
half times the normal price or if you want to engage us on the
weekend, we could do that. So then you stick up this purple
sticky. No by the event before the
event. And so the event that gets
emitted now is based on the pricing policy.
Maybe you have different ones. Is it?
A holiday is the weekend. Is it after hours, then it just
rained a lot and the grass grow very tall because of a lot of
rain, but just things like that. So, another quite related.
Sometimes it is a bit tongue-twisting.
There's another term called event sourcing what is event
sourcing and when should people use event sourcing compared to
traditional database and things like that.
Events or swing users events and a stream of events to represent
some State and a stream, some of your stream and maybe right away
their mind, either thinks automatically the right way, or
they get all confused and they're like, wish you would
just tell us what that really means.
So what a stream is just a collection.
It's an ordered collection of events.
You have your 0th event and you have your empty vent on the
high-end side. And so you what you can do is
take that collection and starting with the first Zeroth
event, interpret that and apply what that event means to your
entity. That owns that event.
Right? But he admitted that even in the
first place and apply that. And you say okay.
I'm going to modify my state my entity State according to what
that event means to my state. And then I'm going to take the
next one, the first element one now, and I'm going to apply that
over top of the other. And then I'm just going to go,
2, 3, 4, 5, all the way to n and I'm going to mutate or modify my
entity State based on those as those events initially happen,
right there. Very much connected to command.
So the entity receives a command says do this, The Entity does
that and any nits need them and that event must somehow
represent the change that needs to happen to that state and you
actually need iately mutate your state based on the event that
you just emitted. But then later, you can also
reconstitute the state of that entity from the Anymore.
Just that ordered collection, that sequence of events 0
through n and we apply them to your state and your stated
recovered. And so why do you use that too
many people use it just because they're interested in it.
What it's really meant to do is to make a record of every
individual thing. Every unique thing that happens
to that entity in the model. And then if you use events
sourcing across every entity type, and every entity instance,
then you, You have this Global stream of everything that's
happened in your model ever over time.
And so a lot of times this is useful in financial systems
where you need to know, okay on such and such a date time, what
happened or opposite, this happen, but it happened at this
point in time. And so you can actually create
not only a total ordering of everything that belongs to that
entity, but a total ordering everything that has happened in
that entire model or bounded to run things.
If you have compliance. To some standards like banking
standards or stock market, standards or whatever.
It happens to be, then that's useful.
I think that many people use it for technical reasons.
The problem with that is a lot of them don't really understand
it. And so they fail with it because
they don't know what they're doing and then they blame events
Force. Oh, you know, it's going to slot
doesn't work. We tried.
It doesn't look. You can't believe how many times
I've read these articles blog posts, whatever and I Go read it
and they tell you up front. I'm never using events
tourmaline. Again.
It's trash. I hated it.
And as you read and you read how they used it, you're just like
from the beginning. They were absolutely long.
The way they described it there telling on themselves and you're
kind of embarrassed for them. Because you're saying, like,
well man, really did not know what you were doing.
But there's no sense in even trying to convince them because
they're never going to admit that.
It was their fault, you know, but it is sort of like, should I
fall embarrassed for them know not.
It's just their own fault. Don't use it just because you
think it sounds cool. But if you have these specific
problems to solve, is probably a good compliance, has to me like
constraints to meet with in a certain industry, then use it.
The Recently, I saw a tweet by you announcing your new book
called strategic model eats and microservices.
And then I also realize that you have a Vaughn, were none series
with Addison Wesley, which is pretty cool.
Would you mind sharing? What is the book all about?
Why do you write this book? Well, Well, first of all, over
the past five, six years, maybe longer, but there's been this
really huge Groundswell around microservices.
If I go back, five or six years. I recall saying like why is
everybody getting so excited about microservices?
Because first of all, according to some people's definition, I
wrote about microservices in my IDE book implementing domain
driven design. I discuss some multiple bounded
context that would match some people's definition of So to me,
it was a really that outstandingly me and I guess
depending on who you talk to microservices may have exist
before my book that I had never heard of them until afterwards.
So there's that but then the definition of like no service
itself has been very problematic.
And so while when I do talk about microservices, I say well
a micro service should probably admission be a bound of
contracts because bounded context are Randy.
Allison sighs. They may be complex as in
solving a complexity, but they generally don't have even dozens
of entity types. I mean, I can't arbitrarily say
that they don't, but I'm just saying in general, they probably
don't. And so, they're probably
smallish anyway, and so just save yourself a lot of heartache
and pain and don't make your microservices too small.
Well, if you go, for example, there's some people looking at
Uber, who just came up with this.
Amazing. Insight that said, well, we've
been using micro services and while they really hurt.
So what we're going to do is rename what we're doing to macro
Services. It's like, okay, wait a minute
people through that name. I'll five years ago.
So you haven't just come up with anything new idea.
So say to yourself all these paps on your own back because
those names have been flown out there and then they get like
three thousand likes on their tweet about this and you just
go. Oh my goodness.
Because they weren't even using microservices the way that
probably people who really think carefully about this and had
experience, we would actually decide to use them.
So if a micro service is one entity large and you have 500
entities, tights in this system or 1,000, just think about what
your brain is going to have to deal with and understanding that
in things that are not really that complex.
We have the ability to understand things in numbers of
And plus or minus 2. When things get complex, we
understand things in 5 plus or minus 2, which means a lot of
brains can only deal with three complex ideas at a time of
Concepts and as many as maybe seven but five maybe average.
Now when you're talking about complex things and you're
talking about hundreds or thousands of them, if you've
ever worked in a system that has a million lines of code.
I have I worked at systems with a couple million lines of point
maybe probably We can relate to that.
If you have two million lines of code in your system and you
follow this single entity idea. You could probably have 20,000
microservices in your system. Just really think about that
first. And that is just crazy.
I don't know who would really sign up for that.
And now the big companies that did all that and thought they
were doing the right thing in the cool thing.
In the whatever thing, they're all regretting it now and
they're saying we should have never have done that.
Now we're going to do that. Consumer sees which are what
right? Size Services.
Tell me what? How do you write size that
service? Oh, maybe you could use a
bounded contacts in a ubiquitous language.
Well, they'll discover that five years from now that they should
have done that because their choices in sizing a macro
service. It's all arbitrary still it's as
arbitrary as it was for the tiny, tiny micro service.
So anyway, I really took you down the rabbit Trail there,
then on the other side, monoliths, boom, monoliths are
so Or below their formal, every single architect in the whole
world. Right now - 10 are saying Model
S are horrible. We got to get rid of all of our
models and it's just not true. What they really mean is if they
have created some really bad monoliths that are known in a
DVD world, as big ball of mud and even outside the D.
I mean, Brian foot and Joey odor came up with this idea, quite a
long time ago, that you can create these big balls in Milan,
go to Wikipedia and look that up and read all Well, we call of
mud. That is what's really wrong with
monoliths. It's like this old show, that
country folk, and even on Country folk in the u.s.
Used to watch a long time ago. It's called Hee-Haw.
I don't know if you ever heard of she if you were in Tennessee
in the US and your hillbilly Newport Country person.
You watched Hee Haw. So did a lot of other people
there is this once get that they would have almost every week on
Hee Haw and the guy would walk up to the doctor.
He would bend his arm or you say doctor, it hurts.
When I bend my arm. The doctors cure for that was
don't do that though, you know? And so if big ball of mud hurts
and if tiny tiny micro service hurts, don't do that, then the
subtitle to the book. So strategic model is a
microservices driving. Change with purposeful
architecture, purposeful. See a very key word.
Purposeful. Everything should have a
purpose. Is there any reason other than
an arbitrary decision that you decided to write?
Only 100 lines of java code and that will be the microservice.
And if it's starting to reach a hundred and ten lines of code or
only 90, will might be something wrong with this micro stimulus
because it's more or less than 100.
So you start adding comments just to make yourself feel
better or deleting comments. Not even the comments or lines
of code. But oh, maybe we can write this
if else on a single line of code, I mean, seriously, when
people are thinking that way there's Something wrong.
There is just really something. Well, what do you mean 100 lines
of code? You need 100 lines of java code
as a good micro service, but then what if I write it in
enclosure and it's 30 lines, if come, is that a bad
micro-service? Should we add more to that micro
service? So that it'll be a hundred lines
of closure. So when I'll be expecting to see
the book, it's not going to be next.
It's not going to be in January. It has to go through production,
but hopefully not long either. I don't have control over.
All that I have control over is writing and actually I have to
admit, I was about six weeks late and my co-author.
So we were just dealing with covid and I haven't gotten
bullet but my co-author did. So he had to deal with that and
his wife want to. So they were sick for three
weeks. I haven't gotten it.
But I've been exhausted just like everybody else for the
whole pending fatigue thing. I think ways on everybody and so
it the book was about six weeks late and being delivered, but,
you know, maybe we'll make up that time similarly.
I'm really looking forward for that one.
Before we end the conversation as usual.
I would ask my guests, three technical leadership.
Wisdom. Would you be able to share those
three wisdom that you have throughout your career for us to
learn? Yeah, right really simple code.
If you're writing code to impress people, you're making a
mistake again. I was just having this
conversation with Dave Thomas today, and I said, you know
what, sometimes I just really like to write imperative code
because it's so clear. It's just this Is what I'm
doing. I don't need to use this other
mapping approach or flat map or map or whatever.
It just is going to be so clear. If I just do a little later and
a loom and it's just going to be crystal clear on.
What's Happening. Someone could look at my code
and go. Hey, well you could have used
math. You know, I mean, yeah.
Well I could have also not insist that too.
So don't feel pressure from the crowd and a peer pressure that
you're not cool enough because you aren't lighting The Stance
and felt whatever it is that But I mean, five years ago,
iterating, this little faults and now it's all wait.
We just heard about functional programming or mopping over a
collection of. Well, let me tell you something
with small talk. I was mapping all the
collections 30 years ago. So there I know how it works.
In fact, that's pretty much how it works is, small talk.
Yeah, I've used land has since the 1980s and so don't tell me
about that, but I don't have to use that because maybe the team
I'm working with, wouldn't understand it as well, and maybe
there are certain. Features, I can't use because
I've limited myself to the Java jdk that I'm using.
So I'm not going to go upgrade to Java 16, just to be on the
absolute Leading Edge so that I can use this feature and say
that I used it. I really don't care about stuff
like that. Business-wise what matters most?
So okay. That's the first one.
Well, and that also leads into the second one.
Is the business matters. They're paying your paycheck,
and I hate to bring it down to that only because paying your
paycheck, it's not just a matter of being.
Ungrateful, but what value do you really offer?
Are you simply a cost center to the business because you get a
paycheck, and what do you give to the business and return?
Are you helping the business in Ali?
Do you think, like a business person?
Go buy some stocks in the stock market and start worrying about
your Investments? Worry about that for a while.
You going to talk about, right? Like we start taking on those
responsibilities. You become really conscious
about the way you spend your money and you're like, well, if
I This Equity looks a little risky and you have start making
decisions like that. Now that's the way your CEO
things. That's the way your CIO.
That's the way your CTL things. They're not just hey, yeah,
let's give so-and-so a big raise this year because they can map
over a collection now, that's not what patters.
So there's that and then I'm just going to say jump back to
the first lady one of the first things we talked about and
that's get out of your cubicle talk.
If you are. An introvert.
Get over it. Sorry.
I'm an introvert on one of the worst introverts ever.
But you know what? We're having this conversation
now, because I'm still an introvert, but I've learned how
to deal with it. And so now I can talk in front
of thousands of people and it doesn't bother me anymore.
I mean, yeah, I do get a little nervous but I can do it and so
learn to do that. And one of the best things you
can do is teach someone and not just someone like teaching
workshop when your company once a year.
Everybody on your team should have Teach 3 to 5 days per year
and I don't mean just teaching for an hour.
I mean, teach develop a workshop one.
You're going to learn way more than you can possibly teach your
students until you can become a very, very good teacher.
Then they'll start to learn as much as you deem.
Hopefully, you can convey that as well.
But it will also get you out of your shell.
We're going to get up there and voice might shake or you're
going to expire a lot. But hey, what was it?
Like when you did your first podcast?
For you nervous? Of course.
She only. Yeah, I mean probably even the
first what? 60 and then you started maybe
getting used to. I don't know.
Maybe it was only 20 for you. But you know, sure you're afraid
of maybe how this is gonna go. But look at you now, you're just
comfortable. We're having a nice time.
I mean, this is just to me. It's a nice conversation.
I'm sure for you too. So you can learn to do that in
any situation and that is what's going to help you be a business
person. Wow.
It's very insightful. Thank you for sharing all that.
Thanks for the tips. Looking forward for the book.
My Said, thanks again. One for spending your time here.
I really learn a lot D. D, D, is something that I would
like to master myself as well as a software programmer.
So, yeah. Thanks for the time and I hope
to see you again in the future episode.
Oh, yeah, absolutely. Thank you, honey.
Thank you for listening to this episode and for staying right
till the end. If you highly enjoyed, please
share it with your friends and colleagues who you think would
also benefit from listening to this episode.
And if you're new to the podcast, make sure to subscribe
and leave me your valuable review and feedback.
It really, really helps me a lot in order to grow these podcasts
better. You can also find the full show
notes of this conversation on the episode page at technology.
No, the death website. Including the full transcript
interesting quotes, and links to the resources and mentions from
the conversation. And lastly make sure to
subscribe to the show's mailing list on technology.
No, the deaf to get notified for any future episodes.
Stay tuned for the next technique Journal episode.
And until then. Goodbye.