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.