#21 - Domain-Driven Design and Event-Driven Architecture - Vaughn Vernon

Episode Introduction [00:00:51]

Henry Suryawirawan: [00:00:51] Hey, everyone. Welcome to a new episode of the Tech Lead Journal in 2021 with me your host, Henry Suryawirawan. Thanks for tuning in and spending your time with me today listening to this episode. After a 2-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 situation in terms of recovering from the pandemic.

If you still remember at the end of 2020, Tech Lead Journal 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 5 lucky winners of the JetBrains All Products Pack Personal licenses. Congratulations to Enner, Daniel, Adinda, Calvin, and Lynn! I hope that the licenses 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 Tech Lead Journal on LinkedIn, Twitter, and Instagram, and make sure to follow the show there.

I’d also like to mention that Tech Lead Journal is also available on YouTube. And during the break, I added a few new playlists 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 playlists, which include each episode short clip, the patron message, and the 3 Tech Lead 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 techleadjournal.dev/patron, and help 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 Vaughn Vernon. Vaughn is a leading expert in Domain-Driven Design and reactive software development. He is extremely well-known for his bestselling DDD books, “Implementing Domain-Driven Design“, or the red book, and “Domain-Driven Design Distilled“, the green book. And he is specially commissioned by Pearson/ Addison-Wesley to curate and edit his very own Vaughn Vernon Signature Series. Vaughn is also well-known for his IDDD workshop, which he has been running for the past 8 years, teaching people how to implement DDD the right way. He’s also the founder of the open source VLINGO/PLATFORM project, a DDD-friendly toolset 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 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, Vaughn also gave a sneak peek 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 hope 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 Podcasts and other podcast apps that allow you to do so. Those ratings and reviews are one of the best ways to get this podcast 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 techleadjournal.dev/feedback. So let’s get the episode started right after our sponsor message.

Introduction [00:06:02]

Henry Suryawirawan: [00:06:02] Welcome everyone to another show of the Tech Lead Journal. Today I’m so excited to have with me, one of the foremost thought 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. He has written few books on DDD. 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 IDDD workshop, which he has run for a number of years. And he also set up a company called VLINGO, which is also doing things around DDD and reactive patterns and things like that. So welcome Vaughn, to the show. I’m so excited to have the conversation with you today.

Vaughn Vernon: [00:06:41] Thank you for inviting me. I’m glad to be here.

Career Journey [00:06:44]

Henry Suryawirawan: [00:06:44] So Vaughn, I know you have a very long illustrious career journey. Maybe for the audience here, can you share some of your highlights and turning points in your career?

Vaughn Vernon: [00:06:53] Sure. It’s funny that you say long and illustrious, I would say long. Illustrious? Well, I think I learned a lot along the way. I have done some very nice work, but I think everyone would consider the road 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 clearing house company, which was basically, the investors were the 11 largest insurance companies in the US. I can’t even remember all of them. I think Aetna was one of the main 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 payment. The sort of core domain behind this insurance clearing house was to set up software that ran on the IBM PC at hospitals. And whenever a patient was admitted, they would basically start filling out their insurance forms right then with data entry and it’s doubled as also record for the hospital. And then, those claims would be submitted eventually whenever all the treatment was identified. 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 insurance companies. And they would be submitted electronically to the insurance companies. Now being that I started working there in 1983, and this was pretty advanced stuff, way back then before there was a main B2B and a lot of integrations so forth. But what I ended up doing was the software that ended up in the hospitals was initially implemented using Microsoft COBOL on the PC. And I’m not sure whatever happened to that, but the COBOL code in executable format took up 10 diskettes. Diskettes at the time, I think were I guess, 256K or something like that. And so it was distributed across 10 diskettes. And every time that a new module needed to be used in the program, the user would be told, switch out whatever to whatever else. Ended up being problematic because there was a lot of shifting of diskettes and then there was another diskette for the data. Sometimes literally, I have a hard time actually remembering, like, I want to say Meg, but I know it’s not Meg, it’s K. And then when I say K, I was like, I just say to myself, wow, that was really, really not much memory, but I was working at it at the time, and it was like, that’s what you had to deal with. So, this is what the environment I was working in.

Well, I read an article on Byte magazine. It was this very influential article. It was on the C programming language. And I think it was 1983-84 somewhere, I think it was 83. I went to the VP of engineering and I said, “Why aren’t we using C instead of COBOL? I think we could reduce the program code to one diskette.” That was my claim early. It was like a total swag, but I said I think we can do it. And I did some calculations, 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 and see, although I didn’t know C 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 EDS, but EDS at the time, it was like, if you had been in the military, you got a job working for Ross Perot and he made a future for you. So all these guys were mostly ex-military of some kind. And so they were very strict, very demanding, very like blue suits with pinstripes and white shirts and the red and blue ties, and they totally looked like IBM or executives at the org, actually anybody at that time. So, I had to wear a suit to work, and that was the way it was. So that’s how I started my career, and I got kind of dent in this very small amounts of code, very tight code, had it work efficiently. That just became part of me for a long time. And 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. Hey, memory is free. Disk is 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 something wouldn’t be performing well. And I would say, “Well, but look, you’re not breaking out of this loop after you’ve 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&R C book, Kernighan and Ritchie book. I think they have binary search in there or something. You just learn these things. And your mindset was Unix and C 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. It’s just a natural kind of… I didn’t spend any time on it. It was just made sense to me like, “Oh, okay, so I can use a binary search. And I’ve even got this function or method or whatever in the library, and I could just use that. And hey, you know 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 Spring Boot, is something like 3 GB just to boot— 3 GB of RAM — and VLINGO is 200 MB start up. 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 C early on. I met a guy that had written some books about C programming. He had been a Bell Labs employee. And he offered me an opportunity to write and co-author a book with him, because I knew Unix system internals. This was for actually the OS2 operating system. And at the time, we didn’t even know what the name would be, but it ended up being called OS2 at the time. We saw that it was called 286 DOS, which was the processor at the time that could support protective mode execution. So you couldn’t address, you couldn’t reference something outside of your address space, 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 Smalltalk, actually probably only seven years. And I got into Smalltalk and this is just like this leap mind-bending experience where I was also programming in C++, but C++ was weird at the time. There was no compiler available. It was only this thing called Cfront, which was a translator. So it would read and parse C++ code, and then generate C, and you had to have a C compiler compiled that, and debugging was just horrendous, because name mangling and all these, you know, you couldn’t recognize the code you were working in. It wasn’t until I think really late eighties that a few companies started coming out with C++ actual compilers. And I think maybe Borland, and there was another little company called Datalight, and a company called Zortech.

So we started to get like some real C++ programming in there. But, at the same time, learning Smalltalk and being introduced to that was just mind blowing. It was like, I was talking earlier today to Dave Thomas, Smalltalk Dave, and we were talking Smalltalk and I told him that when I learned Smalltalk, I saw this some manual or some document I was reading about Smalltalk. I said, “This is the Smalltalk language. And it was one line of code. It explained the entire language in one line of code.” And it just blew my mind, because I don’t think 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 Smalltalk. And I think within two weeks, I went, “Oh, okay, I get it now. I understand why this is the whole language.” But until you get over that hurdle where there are no keywords, there are no everything. Well, there is a keyword called primitive, but that isn’t used in the Smalltalk code. That is a language construct that you have to write like a C binding for something. If you can’t actually implement it in Smalltalk, or if you need to integrate with some library, outside the database, then you use primitive to make a method invoke it well. You sent a message to some object and that dispatch to a primitive method. And that primitive method is where you call actually like a DLL or something outside. So, that was one keyword. But, yeah, so that was like the beginning. And then I got into Java when it was pretty clear that Smalltalk wasn’t going to survive, at least in my world, because there weren’t machines that could run Smalltalk really well. There wasn’t much memory in Smalltalk. Unless you add some special tools, like Envy/Smalltalk, which was Dave Thomas’ company, you 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 20 to 1. So I could outcode 20 C++ program. There was no problem. It was no contest. There was no questions asked. You could just do that anyway. So that’s where I’ve been.

Henry Suryawirawan: [00:16:30] Thanks for sharing that. I mean, it’s really, really great to hear the history, like long time back, even 1983, it was 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.

Domain-Driven Design [00:16:47]

Henry Suryawirawan: [00:16:47] So Vaughn, 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 blue book. It was quite difficult to read, I must say. It’s 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 like even you come up with another book for the distilled version, which is even smaller and thinner, which condensed all the essence of DDD. 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?

Vaughn Vernon: [00:17:22] Probably I explained DDD differently today than I did 8-10 years ago. But, you could start with saying DDD is, you know, ubiquitous language in a bounded context. And right away when you understand what a bounded context is, that it’s this sort of relatively small boundary where your program code is. Your application code is within this boundary. All of it. 100% of a single application. Or if you want to say service, it’s within there. And then you say, wait a minute. But the word ubiquitous means everywhere, throughout, permeating. And then you say, how can that be? Cause 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 lives 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 ubiquitous. It is ubiquitous, completely permeates everything within the context, including conversations that you have as people. And that’s the thing is: all the learning, 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 or specification documents, and say code it up. It’s like you’re really having conversations with the exact people who are very knowledgeable about the area of expertise that you’re working in. And so they’re called domain experts. Or I just like to say business experts, because sometimes the word domain is just not well understood. So I just say business experts within that area of expertise.

I think it’s good to clarify that the word domain, if you look at an English dictionary, and look up the word domain, 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 the idiom, that is a sphere 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’ve cut out this area of expertise and you have ownership of it. It is yours. And you make it what it is. And you 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 on things that’s just not 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, what I described previously, is a core domain. And then in between that, you have something called a supporting subdomain. And a supporting subdomain is something you probably can’t buy, almost never. But you also don’t want to invest a lot in it, but 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 core, because it’s not the same model. And so you separate all these models. And so you have this core domain, or core subdomain. So if there’s a domain that you’re working in, as in a problem space that has a solution, then you have various subdomains within that, and those subdomains roughly mapped to bounded context.

That’s kind of a DDD. Those are the kind of strategic patterns, and then, strategically you’re looking to, okay, I’ve got all these boundaries out, bounded contexts out there, whether it’s core, supporting, generic, how do we integrate all those? And then you 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 the tricky part comes in. But you just have to take your best shot at it, and see how it goes. And then of course, refactor if you don’t quite get it right.

Why DDD Can be Expensive [00:21:43]

Henry Suryawirawan: [00:21:43] When I’m listening to you, I’m interested when you say that it’s not for everything, you’re probably doing it right. It’s very expensive. But can you explain why is it expensive to do it right versus, for example, common programming?

Vaughn Vernon: [00:21:56] Well, it’s expensive because you are really experimenting and having a lot of conversations. And you’re bringing business experts in to be 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 coding for 5 or 10 minutes, and you say, “Wait a minute, we didn’t think of this.” And then you go back. And now 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 leads says, “It’s just names. We can name it anything. It’s just names.” And I just, that’s when you get a twitch in your eye or your shoulder or something and neck, and you’re like, “You know, this is exactly the opposite. No, it really does matter.” Well, maybe it doesn’t matter in that generic place or maybe not even so much in the supporting place, but in the core, it absolutely matters. 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 XP, you’ll see a lot of the thoughts behind DDD forming at that point. And this is where, like XP said, expert always available or customer always available. Customer expert work, 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 when he worked on this, but if you ask him, he was very much influenced by XP. And I think maybe even worked on some of those early XP projects.

Why Developers Need to Know DDD [00:23:59]

Henry Suryawirawan: [00:23:59] 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?

Vaughn Vernon: [00:24:13] Because this is where innovation occurs. If you go back to the days of Thomas Edison. Thomas Edison said, “Some people will say that I failed 6,000 times.” He said, “I didn’t fail 6,000 times. I just found out 6,000 ways that didn’t work. And then 6,001 did.” It wasn’t just Thomas Edison doing that. He had a whole army of, I think he had a thousand scientists sort of 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 6,000 experiments that don’t work? And how long did the experiments last? How long 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 the street lamps in the early days. That would burn out rather quickly. Now you had a filament that lasted a long time comparatively. In the end, the experiments paid off. And he innovated. 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 be involved with the business experts, and find where investment needs to be made to innovate. You know, maybe 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 that with rockets, with spaceships. Because, hey, he reuses them. I mean, they take off and they land. So there’s an innovation. But is the way that he calculates trajectory and path and so forth absolutely completely unique from the way NASA or whoever launched rockets before? Probably not. Probably very similar. But that’s not his core domain. The core domain is launching that baby, and bringing it back, and not throwing away millions of dollars every time. But the logic, that’s the core domain. So there’s the innovation. And so that’s the thing is, right now, in SpaceX, 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? I mean, they go buy the fuel somewhere. And they buy some components and things that are generic. But the core is, okay, we need some way to not destroy this rocket and dispatch a bunch of it into oceans around the globe as it’s flying, and bring it all back and be able to reuse it. And that’s the core domain. There’s the innovation.

Henry Suryawirawan: [00:26:50] So when I read about DDD, a lot of things seem to be closely tied with object-oriented programming. Can DDD also be applied to functional programming?

Vaughn Vernon: [00:27:00] Oh, sure. Well, yeah, I think you would say is that, can functional programming be applied to a core domain? Absolutely. In 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.

DDD Most Important Thing [00:27:15]

Henry Suryawirawan: [00:27:15] So you mentioned a number of things like ubiquitous language, bounded context, core domain, generics domain, and things like that. What do you think are some of the basic, most important concepts that people should get in order to understand DDD?

Vaughn Vernon: [00:27:29] Programmers have to come out of their cubicles. I mean, that’s funny cause nobody’s in cubicles these days, I think. Maybe a few, but 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 keep bringing them pizza or ramen every day and noodle bowls or whatever. And they just keep eating and churning out this incredible code. Because it’s not just even about code. Anybody can write code. It’s about what does the code accomplish. And if the code accomplishes something innovative, great! But there aren’t too many single individuals, even if they’re great coders, there aren’t 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 actually symbiotic need to be engaged with the business, and the business with developers. Because look, Marc Andreessen said ages ago, internet time ages ago, it’s been 9 or 10 years now. He 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. It’s online. Every company is now a software company. If you aren’t there, if you still consider software a cost center in your corporation, and if that mentality lingers 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 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, oohh, 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 been pushing papers 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 innovate around it.

Henry Suryawirawan: [00:29:47] 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, and then innovate with them. Because one of these days, software is going to be really, really critical for every, every company in the world.

How to Start with DDD [00:30:05]

Henry Suryawirawan: [00:30:05] For those people who are new to DDD, how can they start actually?

Vaughn Vernon: [00:30:09] Well, I’ve got two books. I would suggest read “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 Distilled. And then use that red book, Implementing Domain-Driven Design as the 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 DDD and how do we use it? Into, Oh, let me now read what was on Eric’s mind for the five years he was writing his book and his experience. And you’ll see that, then 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, DDD is not about coding. It is, but it’s not initially about coding. And so what a lot of developers want to do is, they see the tactical tools and they’re like, “Ooh, I need to use aggregates because if I use aggregates, then I’m using DDD.” 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 these. How do you even know you need an aggregate in this case? Maybe you shouldn’t use an aggregate there. But you won’t know until you have the conversations. Is this thing that we are talking about, does it have unique identity? And do you 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 gonna 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, all these recruiting places that say like domain expert for such and such a company. It doesn’t happen. So it’s someone who 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 this way, because they probably won’t actually know that. You have to have conversations.

Event-Driven Architecture [00:32:28]

Henry Suryawirawan: [00:32:29] Another thing that is also quite related to domain-driven design is actually event-driven architecture, because you have a 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, event-driven design kind of thing?

Vaughn Vernon: [00:32:44] Well, event-driven architecture involves events. I don’t want to sound too obvious. But you have a number of services, let’s say, or applications within a whole system, and each of those applications is emitting events that have some meaning to the overall system, or at least some services or other applications within the system. And when you emit 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, oh, just document created or document edited or anything like that. What does that mean over here in this other application? So when you receive 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 your own events. But that is where the events are 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 an event that has a meaning to them. And so you’re probably using a message bus, or some sort of messaging, messaging middleware, or cloud messaging, or whatever, Kafka, everybody wants to talk about Kafka. You know, it’s just whatever you need to get events distributed.

Now, 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 emitted that event and published that event to you. And now whenever that event 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 is part of its ubiquitous language. So this is where EDA and DDD work together. So we’re now saying, okay, we don’t want our model to be a conformist to the other model. Because if it was a conformist, right now maybe you’ve seen that pattern in DDD, what’s a conformist. Actually, sometimes a conformist 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 conformist 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 and all 50 of those other services or applications 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, the event part of it, is quite important then.

Benefits of EDA [00:36:00]

Henry Suryawirawan: [00:36:00] Is it fair for me to understand that when you implement the event-driven architecture, basically you make your system more adaptive to change, more flexible? Or is there other benefits that come out of the EDA?

Vaughn Vernon: [00:36:12] If you do what I just described in creating commands from the events, that does help with decoupling. But there is still the fact that you now depend on, even at the boundary, even an incoming request or a message delivery, you have a bit of coupling there, and so you’re going to have to take on the 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 decoupling. You’re not like something saying, “Let me query something over on that service and see what it tells me. And then if it doesn’t happen in time, I’ll time out. And maybe I have to like, fail something, clear back to the user.” Instead, like I said, you’re passive and you’re reacting to what you’re told at any given time. And that latency is actually good. Because now instead of making all your REST requests or all your RPC requests say, “Oh, if I don’t get an answer within five seconds, something is broken.” Well, I mean, how many times in a day there’s something takes six seconds instead of three? Or seven seconds instead of five? And so you put this arbitrary timeout on your REST client, right? You just say arbitrarily, “Oh, well, let’s put a five 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, they’ll say, “No. I mean, that thing could take half an hour, and it would be no problem at all. Or even tomorrow would be okay.” But what happens with developers? They’ll just go, “Oh man, we need performance. So, we’re going to put a timeout on this. And we’ll just start failing transactions left and right if 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, hey, 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 programmer’s decision. That’s not a software developer’s decision. Too much latency is the decision of the business. And you simply have, 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 timed out.” Somebody 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 $200 million to build. Let’s just cancel it because something timed out after two hours. No! You deal with it in a logical business way. You tell someone, “We didn’t hear about this. Maybe something didn’t go right.” Or, was it just the technical failure? Is there a way to get that back on track by clearing, delivering out all the dead letter queue or something? But you’re now saying, I mean, it’s not the end of the world. Before we had computers, we dealt with stuff like this all the time. There may not be many people that remember those days. Depending on the domain, the business that you’re working in, they probably do. Probably still are a lot out them dealing with those things.

Eventual Consistency [00:40:13]

Henry Suryawirawan: [00:40:13] It’s interesting listening to you talking about this time decoupling and all this latency. So I think it’s really tightly related to eventual consistency pattern. So, do you think that most of the things should be implemented using eventual consistency way, like hearing what you’re saying just now? Or you should confirm with the business, what is actually needed for atomic transaction? And while the rest of it, if the business confirms, “yeah, we don’t need straight away”, maybe we can use eventual consistency.

Vaughn Vernon: [00:40:40] Yeah, exactly what you said. And the thing is, if two, 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 a 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. But I’m just saying, I think you would be surprised. And I have these conversations relatively regularly, and I asked those questions. They were 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 5 or 10 seconds have passed. But in normal situations, 5 or 10 seconds is plenty of time for that compensation to have occurred, 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 toward it. And then a way around that is, instead of making the user drive that, you simply make the UI reactive to WebSockets or Server Sent Events or 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 whenever this is ready, we will show it to you.” And so they’re never taught to be concerned about that.

Henry Suryawirawan: [00:42:33] So I think one of the things 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 library will 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?

Vaughn Vernon: [00:43:01] Interesting. It’s like almost every day you have a conversation with someone that kind of influences the way you think. And today, I had 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 DDD wants to deal with this eventual consistency. So for example, implementing sagas or process managers may not be the best thing for any given individual. Well, I’m going to have a couple of deep dive workshops in January where I teach that very, very thoroughly. But if you’re not ready to deal with process managers, it could well be that you really don’t need to create a saga or a process manager. And even though as much as you may really relish the idea of doing this kind of work, it’s going to make you a cooler software developer for doing it, maybe choreography will work fine. And so you will just react to events that show up. And as long as the process isn’t super complex, then 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 a process manager or that orchestrator, in contrast with choreography, you can go to that orchestrator at any time, and say, “For this thing, this process that began, where did it get stuck? Where did 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.” Why? It could be technology went bad. Or it could be that someone has a bug in their code. Or it could just be that it’s in someone’s workflow, and they didn’t approve it yet. 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. Click a button. And maybe that’s all. You just need to go make a phone call and say, “Hey, did you receive this? And if you did, could you please approve it?”

Event Storming [00:45:22]

Henry Suryawirawan: [00:45:22] Another thing that normally when you start with DDD, right, it 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 how does it play an important role in coming up with a good DDD?

Vaughn Vernon: [00:45:48] So, event storming is an activity in lightweight modeling. And there are two levels of event storming, let’s say. The first level that you 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 core domain. 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. Now I’m just going to talk about the standard colors that have been chosen for sticky notes as this traditional, or I hate to call it standard, but the point is that it’s what people are taught to use. Sometimes you can’t find those colors of sticky notes, physical ones in packages. And if that’s the case, you can change them up according to what you do have. But I’m just going to talk about the standard ones. So orange colors are for events. So you write the name of an event that happens, and this is primarily what you’re working with the event storming, and you stick that sticky note on a modeling surface, which is just this sort of limited height, maybe one meter high, but maybe 10 meters wide or 15 meters wide, and you have this modeling space, and every single sticky note that’s put up there, is put up there relative to the time that it occurs.

And so you may actually start in your big picture modeling in the middle of your timeline. 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, we’ll start to understand what happens before that, and we’ll 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 the purple sticky, purple-ish 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 there is sort of business rules. And, I mean, 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 the week. Probably, at certain times of the year, you have even certain timeframes where you don’t want to be out in the hot sun, but you’ll do it for some extra money. Or we normally don’t want to work after 5:00 PM 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 6:00 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 can do that.” So then you stick up this purple sticky note 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 it a weekend? Is it after hours? Did it just rain a lot? And the grass grew very tall, because of a lot of rain. And just things like that.

Event Sourcing [00:49:13]

Henry Suryawirawan: [00:49:13] So another quite related, sometimes a little 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?

Vaughn Vernon: [00:49:25] Event sourcing uses events and a stream of events to represent some state. And a stream… Someone hears stream, and maybe right away their mind either thinks automatically the right way, or they get all confused, and they’re like, wish he 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 zeroth event, and you have your N event on the high-end side. And so what you can do is take that collection, and starting with the first or the zeroth event, interpret that, and apply what that event means to your entity that owns that event, right, that emitted that event 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. Then I’m just going to go two, three, four, five, all the way to N, and I’m going to mutate or modify my entity state based on those. As those events initially happened right there, they’re very much connected to command. So the entity receives a command, says, “Do this.” The entity does that, and it emits an event. And that event must somehow represent the change that needs to happen to that state. And you actually immediately mutate your state based on the event that you’ve just emitted. But then later, you can also reconstitute the state of that entity from the stream, or just that ordered collection, that sequence of events, zero through N, and reapply them to your state, and your state will be 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 event sourcing across every entity type, and every entity instance, then 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 happened 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 context. 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 event source, “Oh, event source or not. It doesn’t work. We tried it, it doesn’t work.” You can’t believe how many times I’ve read these articles, blog posts, whatever, and I go read it, and they tell you upfront, “I’m never using event storming again. It’s trash. I hated it.” And as you read, you read how they used it. And you’re just like, from the beginning, they were absolutely wrong. The way they describe it, they’re telling on themselves. And you’re kind of embarrassed for them, because you’re saying like, “Well, man, you 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 it, that it was their fault. But it is sort of like, “Should I feel embarrassed for them? Well, maybe not. Maybe 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 compliances to me, like constraints to me within a certain industry, then use it.

Vaughn’s New Book [00:53:09]

Henry Suryawirawan: [00:53:09] So recently, I saw a tweet by you, announcing your new book called “Strategic Monoliths and Microservices”. And then I also realized that you have a Vaughn Vernon Series, with Addison-Wesley, which is pretty cool. Would you mind sharing what is the book all about? Why do you write this book?

Vaughn Vernon: [00:53:25] Well, first of all, over the past 5-6 years, maybe longer, but there’s been this really huge groundswell around microservices. If I go back 5 or 6 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 IDDD book, “Implementing Domain-Driven Design”. I discussed some multiple bounded contexts that would match some people’s definition of microservice. So to me, it wasn’t really that outstandingly unique. And I guess, depending on who you talk to, microservices may have existed before my book, but I had never heard of them until afterwards. So there’s that. But then the definition of microservice itself has been very problematic. And so while when I do talk about microservices, I say, well, a microservice should probably initially be a bounded context. Because bounded contexts are grandiose in size. 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 small-ish 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 working at Uber who just came up with this amazing insight that said, “Well, we’ve been using microservices. And wow, they really hurt! So, what we’re going to do is rename what we’re doing to macroservices.” It’s like, “Okay, wait a minute, people threw that name out 5 years ago, so you haven’t just come up with anything new idea. So save yourself all these pats on your own back, because those names have been thrown out there.” And then they get like 3,000 likes on their tweet about this. And you just feel, “Oh my goodness.” Because they weren’t even using microservices the way that probably people who really think carefully about this and had experience would actually decide to use them. So if a microservice is one entity large, and you have 500 entities types in this system, or a thousand, 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 seven plus or minus two. When things get complex, we understand things in five plus or minus two, which means a lot of brains can only deal with three complex ideas at a time, or 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 in systems with a couple million lines of code. Maybe you probably can relate to that. If you have 2 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 and the cool thing and the whatever thing, they’re all regretting it now, and they’re saying we should have never have done that. Now we are going to do macroservices. Which are what? Right-sized services. Tell me what, how do you right size that service? Oh, maybe you could use a bounded context and a ubiquitous language. Well, they’ll discover that five years from now. They should have done that, because their choices in sizing a macroservice, it’s all arbitrary still. It’s as arbitrary as it was for the tiny, tiny microservice. So anyway, I really took you down the rabbit trail there.

Then on the other side, monoliths. Ooh, monoliths are so horrible. Oh, they’re horrible. Every single architect in the whole world right now, minus 10 are saying, monoliths are horrible. We got to get rid of all of our monoliths. And it’s just not true. What they really mean is, if they have created some really bad monoliths that are known in the DDD world as big ball of mud, and even outside the DDD world. I mean, Brian Foote and Joe Yoder came up with this idea quite a long time ago that you can create these big balls of mud, and go to Wikipedia, and look that up, and read all about big ball of mud. That is what’s really wrong with monoliths. It’s like this old show that country folk, and even non-country folk in the US used to watch a long time ago, it’s called “Hee Haw”. I don’t know if you ever heard of Hee Haw. If you were in Tennessee in the US, and you’re a hillbilly, or a country person, you watched Hee Haw, so did a lot of other people. And there was this one skit that they would have almost every week on Hee Haw, and a guy would walk up to the doctor, he would bend his arm and he say, “Doctor, it hurts when I bend my arm.” And the doctor’s cure for that was “Don’t do that then.” You know? And so, if big ball of mud hurts, and if tiny, tiny microservice hurts, don’t do that then.

The subtitle to the book, so “Strategic Monoliths and Microservices: Driving Change With Purposeful Architecture”. Purposeful, the very keyword, 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 110 lines of code, or only 90, there might be something wrong with this microservice, because it’s more or less than a hundred. So you start adding comments just to make yourself feel better or deleting comments, not even the comments are 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 wrong. What do you mean a hundred lines of code? You mean a hundred lines of Java code is a good microservice? But then what if I write it in Clojure, and it’s 30 lines of code? Is that a bad microservice? Should we add more to that microservice so that it’ll be a hundred lines of Clojure?

Henry Suryawirawan: [00:59:44] So, when are we expecting to see the book?

Vaughn Vernon: [00:59:47] 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 that. 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 COVID, but my co-author did. So he had to deal with that, and his wife got it too, so they were sick for three weeks. I haven’t gotten it, but I’ve been exhausted just like everybody else. The whole pandemic fatigue thing. I think weighs on everybody. And so the book was about six weeks late, and being delivered, but you know, maybe we’ll make up that time some of the day.

Henry Suryawirawan: [01:00:24] I’m really looking forward for that.

3 Tech Lead Wisdom [01:00:26]

Henry Suryawirawan: [01:00:26] So Vaughn , 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?

Vaughn Vernon: [01:00:38] Yeah. Write 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 an iterator in a loop, and it’s just going to be crystal clear what’s happening. Someone could look at my code and go, “Hey, well, you could’ve used map. You know what I mean?” “Yeah, well, I could have also not used map too.” So, don’t feel pressure from the crowd or peer pressure that you’re not cool enough because you aren’t writing this fancy code, whatever it is. But I mean, five years ago, iterators were fancy. Now it’s, “Oh wait, we just heard about functional programming and mapping over a collection.” Well, let me tell you something, with Smalltalk, I was mapping over collections 30 years ago. So there, I know how it works. In fact, that’s pretty much how it works in Smalltalk. Yeah, I’ve used Lambdas 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 job or the JDK that I’m using. And so I’m not going to go upgrade to Java 16 just to be on the absolute bleeding 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 grateful. 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 in return? Are you helping the business innovate? 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 know what I’m talking about, right? Like when you start taking on those responsibilities, you become really cautious about the way you spend your money. And you’re like, “Well, if I bought this equity, it looks a little risky.” And you start making decisions like that. Now, that’s the way your CEO thinks. That’s the way your CIO. That’s the way your CTO thinks. 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 matters. So there’s that.

And then, I’m just going to say jump back to the first, maybe one of the first things we talked about, and that’s “get out of your cubicle”. Talk. If you’re an introvert, get over it. Sorry, I’m an introvert. I’m 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 teach a workshop in your company once a year. Everybody on your team should have to teach three to five 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 do, hopefully. You can convey that as well. But it’ll also get you out of your shell. You’re going to get up there, and your voice might shake, or you’re going to perspire a lot. But, “Hey, what was it like when you did your first podcast? Were you nervous?”

Henry Suryawirawan: [01:04:25] Oh, of course! Surely.

Vaughn Vernon: [01:04:27] Yeah. I mean, probably even the first what? 50? 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 going to 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.

Henry Suryawirawan: [01:04:44] Right.

Vaughn Vernon: [01:04:44] So you can learn to do that in any situation, and that is what’s going to help you be a business person.

Henry Suryawirawan: [01:04:49] Wow. It’s very insightful. Thank you for sharing all that. Thanks for the tips. Looking forward for the book, like I said. Thanks again, Vaughn, for spending your time here. I really learned a lot. DDD is something that I would like to master myself as well as a software programmer. So yeah. Thanks for the time. And I’ll hope to see you again in the future episode.

Vaughn Vernon: [01:05:06] Oh yeah, absolutely. Thank you, Henry.

– End –