You probably don't need microservices - Learning Domain-Driven Design by Vlad Khononov

Carter (00:00)

I think microservices are probably one of the biggest victims of like cargo culting in the industry.

Hey there, this is Book Overflow, this is a podcast for software engineers by software engineers, where every week we read one of the best technical books in the world in an effort to improve our craft. I'm Carter Morgan and I'm joined here as always by my co host Nathan Tops. How you doing, Nathan?

Nathan Toups (00:24)

Doing great. Hey everybody.

Carter (00:26)

You know, we do that intro every week and you you kinda wonder like, is it contrived? And maybe it is. I don't know. But I did we did get a YouTube comment on a recent video from a completely new listener who quoted the intro and he was like immediate subscribe. So I was like, Hey, at least you know exactly what the podcast is about 10 seconds into it. So

Nathan Toups (00:46)

I f I feel like a coffee

mug with with us saying that intro would be great one day.

Carter (00:49)

We should get that.

Mine will mine will have the intro and it'll be th six lines long. And yours will yours will just say, Hey everybody. Yeah, true.

Nathan Toups (00:55)

That'll be on one side. And then maybe Yeah, no, yeah. Doing great, hey everybody. And

maybe it only shows up when you actually put like a hot liquid in it. You know, it's like one of those like eighties eighties style ones.

Carter (01:05)

that'd be nice. My brother,

my brother made one of those for my sister-in-law. but it did not have the book overflow intro. but yeah. Well, anyhow, everyone, like, comment, subscribe, share the podcast with your friends and coworkers. You can join the Discord, you can book time with us on Leland, all of that's in the episode description. And also check out our interview with Mark Richards and Neil Ford. this was really cool. We'd actually reached out to them separately to interview both of them.

Nathan Toups (01:10)

That's awesome. Yeah, well that's what it was missing.

Carter (01:31)

And then they found out from each other. They're Hey, you're doing Book Overflow too. And they're like, Why don't we just do it together? So we had both on at the same time. super fun to have both of them. Mark Richards was the very first person we ever interviewed on the podcast. So great to have him back on. I really enjoyed that interview. What did you think, Nathan?

Nathan Toups (01:48)

Yeah, it was awesome. It was cool having them both on at the same time because they they really you can see how they play off of each other and they really complement. And Mark Richards, I don't know if you know this, he also has a YouTube channel that every every Monday he has like some little principle of software architecture that goes up and it's it's it's pretty good. So if you're I would say that the Venn diagram of overlap and interest would be quite high. And if you're not a subscriber, you should go subscribe to his YouTube channel.

Carter (02:01)

it does.

There we go.

We're gonna form like the Avengers of software engineering YouTubers that aren't like hot takes. Like, you know, we're not gonna like the Primogen or, you know, Theo or whatever. But yes.

Nathan Toups (02:26)

Which i are are amaz I like I keep track of those guys,

but I'm I also am like I'm not this witty. I can't do the banter. I don't have a hot take on everything.

Carter (02:32)

Yeah.

yeah, it's gonna be like us and Carl Brown and Mark Richards. Anyhow, it'll be like the the competing adventures or like the Justice League. anyhow, we're excited. We we got our last episode today on learning domain driven design. And then and you know what? I'm just gonna plug this right away. We had an interview with promo Satalage. we usually don't advertise that those have happened before

We actually get it edited and released and everything. But I I just want to say my wife is due with our fifth child and first daughter any day now. I think the due date is technically the 21st, but we've never made it to a due date with a pregnancy. and so promote will likely be part of my small paternity leave. We'll we'll release that episode on like a a regular Monday. And so when that comes out, please check it out. I really enjoyed chatting with Promode and we were talking before we actually start recording Nathan,

He's he's the data expert at ThoughtWorks and collaborates on the kind of the data sections for Mark and Neil's books. and Nathan, I I thought it was funny what you were saying about how he's probably saved ThoughtWorks but d countless times. Yeah.

Nathan Toups (03:46)

yeah. Because data inevitably

is part of the hard parts, right? Like he he was in evolutionary building evolutionary architecture's co-author. he's been at ThoughtWorks for I think he said twenty eight years. recently went back and got his master's degree so he could do some some teaching at the universities and stuff. So really really cool guy. and isn't as public of a figure as like Neil Ford. And so it's a an amazing opportunity to kind of like pick his brain and hear what he's excited about and his views on stuff. So that was a lot of fun.

Carter (04:00)

yeah, yeah.

Yeah, so when that comes out, please watch it. And I I just I have no idea when it's gonna come out. It'll come out when my daughter's born. and when my daughter's born, I will post pictures in the Discord and on the YouTube channel for all to see. okay, but aside from that, we've got our last week, our last episode of Learning Domain Driven Design by Vlad Kononov. As far as the author introduction, we have Vlad Kononov is a software engineer with over 20 years of industry experience, during which he has worked for companies large and small in roles ranging from webmaster to chief architect.

Nathan Toups (04:22)

Thank you.

Carter (04:45)

Vlad maintains an active media career as a public speaker, blogger, and author. He travels the world consulting and talking about domain driven design, microservices, and software architecture in general. Vlad helps companies make sense of their business domains, untangle legacy systems, and tackle complex architectural challenges. He lives in northern Israel with his wife and an almost reasonable number of cats. For the book introduction, we have building software is harder than ever. As a developer, you not only have to chase an ever changing technological trends, but also need to understand the business domains behind the software.

This practical book provides you with a set of core patterns, principles, and practices for analyzing business domains, understanding business strategy, and most importantly, aligning software design with its business needs. And I just want to comment on this idea of ever chasing, ever changing technological trends. This is kind of the first time in my career I've been advanced enough and high up enough that I've been really dealing with kind of like some higher level stuff and like pattern setting and choosing things and

I I was finding myself frustrated with some of like, you know, it's like there's a new AI hot take every week. And it's like, if you're not doing this with your agents, you're falling behind. And like I was just getting frustrated. I was like, gosh, like now we're gonna have to talk about this at work. I was like, I can't wait for this whole AI craze to maybe for the hype cycle to to wane a bit, and then you know, we don't have to deal with that anymore. And I was just kind of thinking about what Carl Brown told us, like, it's always been like this. There's always some hype cycle in tech, right? And so

Nathan Toups (05:51)

Yeah.

Carter (06:11)

this one might die down, but then we're gonna have to talk about why we're not using blockchain or why we're not using Mongo, or using microservices, or whatever, right? So

Nathan Toups (06:18)

Yeah. I I

I've we we've talked about this in the past too. I think that hearing those critic those counter those sort of counter argument voices is really important. For if you haven't watched it, Georgi Oraz had Kelsey Hightower on Pragmatic Engineer recently, and it's almost three hours long. So I just like brace you can watch it in in pieces, and I've gotten about halfway through. I've just been busy with other things, but I will tell you it's worth

Carter (06:34)

Well, I gotta watch them.

Nathan Toups (06:46)

Every moment because Kelsey is just an amazing human being. I know I've talked about how cool he was in the past, but he has this really excellent argument as to like why there's not a lot of empathy for a lot of the tech layoffs and stuff that are happening. Because like in engineering in general, like we've been kind of like consolidating a lot of jobs outside of our industry for a while because of automation. and that you know.

Things are coming around and the job is fundamentally changing. And it's just a really great conversation about, you know, sort of thinking through these problems, which is what Kelsey is so amazing at. It's why he became a distinguished engineer at Google. You can just see how how incredible he is at just getting to the the the actual the point of something. so yeah, it's it's really interesting. And and I guess, you know, I'll tie this into my general thoughts. I'm gonna hop right in here. so

Carter (07:39)

There we go.

Nathan Toups (07:41)

I learned a lot about domain-driven development. This is what the point of the book is. And I will tell you, I got roasted in the comments. I wanted to give a shout-out. two things I really wanted to bring up. Number one, parts don't validate. I we will absolutely talk about this today. I think it's a really important conversation to have. I think it's actually whether folks realize it or not, also a critique of DDD. not that you shouldn't use it, but I think that there are new ideas that have come in that are not necessarily object-oriented.

And I think that was what my critique was. They're not object oriented, but they are type driven development. It's this idea of like really thinking about the thing you're manipulating and can you make sure that it's like categorically not possible to do the wrong thing? Right. I think that's a lot of what we're trying to think about with DDD in this book. The other thing I got roasted on is event driven architecture versus event sourcing. man, did I muddy the waters? they I will I will I will defend aspects of what I was talking about.

But I'll also talk about where the confusing parts where I was also a little bit confused in mixing my definitions. there's a very clean separation. And in this section of the book, he even addresses this. There's like a whole chapter that's like, hey, you might think that the event-driven architecture is event sourcing, but they're not. And here's why you could be confused. And it was literally what I was confused about. so our listeners called us out or called me out mostly, and I wanted to address that too. I really appreciate feedback.

Carter (09:01)

Ha ha ha.

Nathan Toups (09:09)

I I loved I thought everyone's heart was in the right place and I thought it was it deserved the critique and criticism. And so yeah, anyway, this is been this book has made me think a lot, both about DDD, because I hadn't had a formal education in it, in that I think that this has been really influential over the last 20 years, the the Evans book, the blue book. but I also don't I'm not necessarily a DDD

zealot. Like I think there are folks that are sort of in the the priesthood of D D. I am not in that priesthood, though I do think that it made it really valuable contributions. And I think that there are some new ideas that have built upon the best parts of D D that I think are useful regardless of, you know, where you fall. So

Carter (09:41)

Mm.

Yeah, I

I've enjoyed this book. I think this has been my first exposure to domain-driven design as a concept rather than like just kind of hearing about it. it's I just talking about again roasted in the YouTube comments. You said you want to do the w the waters. I certainly didn't help. but I you know, I I hope people who listen to this podcast understand that, like, hey, Nathan and I are learning here too. And if you're coming to this podcast for like, this is these are the experts, these are the guys who are gonna, you know.

Show me everything I should do and how I should do it. Like, yeah, you know, you're you're not gonna get that here. But hopefully what comes across is that we're curious, we're eager to learn, and you're learning right along here with us. yeah, this is this is a very solid introduction to domain driven design. I think this book can be skimmed in parts. I don't think that's necessarily a bad thing. And I know we've specifically talked to authors in the past who are like, Yeah, I I wrote the book that way. It's like if you feel like you've got a good handle on this, like don't don't read this section, you know, jump.

ahead to the next section. and you know, I I always like a a book that's nice and readable. So we're gonna take a quick break and then we'll be back and we'll talk all things learning domain driven design.

Okay, chapter twelve finishes part three, which is what we talked about last week, which is all about, you know, event sourcing, event driven architecture, right? He proposes this concept called event storming, which is really just like a practice you can do with your team. You basically get everyone in a room, you hand out sticky notes and markers and you know, all those fun things, and you're trying to basically brainstorm.

All of the different events that could happen in the system. you know, I think he he constantly uses like a marketing CRM, right? But like the idea that, like, okay, campaign created, campaign published, material added, things like that. I thought this was neat. I think I I I like I like any book that kind of set teaches you like, okay, here's the technical concept, and then here are ways you could kind of try to apply it in the real world.

and I think this is a really good way to kind of get in the mindset of like what domain driven design is. And I like this kind of tight coupling between event driven stuff and domain driven design stuff because it it does kind of force you to think about like, okay, what are all the things that happen in our business? And if you're thinking about all the things that happen in your business, naturally you're thinking about events and domain driven design.

Nathan Toups (12:30)

Yeah. one of the things he gets later into this chapter that I think is the real takeaway for me was that the facilitation of this activity is actually more important than the specifics of the techniques. And what I mean is he gives you this whole layout of like, here's the different types of sticky notes and here's how we describe stuff. But I think the most valuable part of this is it's a ritual where you get you use ubiquitous language, right? We talked about that all the way from week one of this book, which is using the vocabulary.

Of the domain experts that as a software engineer, I really need to like if it's we're dealing with the marketing team, we don't need to come up with a bunch of new terminology. We don't need to go research, you know, some ivy ivory tower, you know, vocabulary list of marketing terms in the industry. What we really need to have is the marketing team, marketing leadership company sitting there in the room with you, describing it in the language that they understand, and us really.

Carter (13:00)

Right.

Nathan Toups (13:26)

sort of breaking it down and being like, okay, when this happens, this happens and this is related to that. And like really sitting down. and of course, this gives you a framework of like this 10 step process of, you know, breaking it all out. And I do think that that's valuable. I think following that implementation. But I just know that like it getting those folks together and just concentrating as a group, it's it's kind of like when as engineers, we're doing pair programming or we're doing mob programming.

Carter (13:53)

Right.

Nathan Toups (13:54)

Where we're kind of attacking a problem and we're like rapidly iterating through like making decisions, unblocking things, thinking about stuff we aren't thinking about. And it's like, I I think that a lot of other parts of the company don't necessarily take a big problem and break it down into problems methodically like engineering does. And again, I I loved this. I I it's not a event storming has kind of like an exciting name to it. It very much overlaps with the DDD concepts.

He also warns, and I think this is interesting, that there's like two schools. One of them thinks that it's impossible to actually effectively do event storming remotely. I yeah, I thought that was interesting too, right? It's like towards the kind of like a little thing at the end. I think that maybe this has changed with some of the tools like mirror boards and other stuff that's possible. I do think that it may be true that there's an energy when you're all like in a room and somebody orders lunch for the team, and you're really just kind of like.

Carter (14:33)

Interesting.

Right.

Nathan Toups (14:52)

Buckled down trying to solve it. And then this is, I'm a remote first person, right? Like I'm like all about 100% remote. I definitely think that the energy of trying to like attack something like this in a room together is unique. And that you really will have to like, I think they said you have to basically reduce headcount, and that you have to really make sure that you're very intentional and not distracted to do this remotely. And I think that's probably like astute observations, right? We can't have.

fifteen people in a Zoom call for eight hours in effectively doing event storming session. Where in person you could Right, exactly. You could torture everyone with this. but yeah.

Carter (15:23)

Right, yeah. Or can you? Yeah. Yeah,

I we haven't talked about it in a while, but I find that really fascinating, like in person dynamics versus remote dynamics. And I think one of the one of the biggest problems with like doing these things remotely is that you forget in a room how helpful it is to be all just turn to the person next to you and like whisper something.

And you can't do that in a Zoom. and I I thought about that. I'm like, someone could you solve that problem? Like, I wonder what that looks like. We're like more efficiently using breakout rooms. Yeah, we haven't had a good remote discussion in a long time, which is because I'm I'm coming up on a year at my current company, which is five days five days a week in person. which people ask me, like, well, do you like being in person? I say, I like being in in this office with these coworkers, right? Like, I

Nathan Toups (16:06)

Mm-mm.

In person, right? Mm-hmm.

Carter (16:20)

My my office is a a 10 minute bike right away. Like I really enjoy all of my coworkers. And so at this time and season of my life, I it's a very good fit for me. and I do think you form deeper bonds when you're in person. But I'll also say that like recruiting is so stinking tough in person, right? Like if you're trying to have like a we try to keep a pretty high bar. And when we were trying to just add another senior to the team, I think we interviewed like,

I think we had like 10 candidates make it to like the the in-person interview. Only two made it to like the final round, which was I thought good. Like our interview process isn't like, you know, we're on a chicken run with our head cut off. but yeah, like finding good talented people. We're in Utah. And so there's a good amount of tech talent out here, but it it's not like it's it, you know, it's

It's on both sides of it, right? Because it's like there's not as much tech talent like the Bay Area, obviously, but there's not nearly as much competition in hiring as the Bay Area. anyhow. So I as far as like event storming goes, like, yeah, I can see how this would be a lot easier in person, but I'm with you. And when it comes to like remote first, I I think there are very few things you you can't do in a remote first environment, especially if you are thoughtful.

about it. And actually like my last company was one of the kind of like fang adjacent companies that went full remote during the pandemic and stayed there. And like I actually really liked them. They had a lot of thoughtful ideas about how you operate in a remote only world, which I I thought they got done pretty well.

Nathan Toups (17:57)

Right. Well

and we see this, right? Like there there are examples, and again, you know, just kind of riffing on the remote first piece, there are you it's a cultural thing. You you really have to intentionally do it. And we also know that some of the l the the largest scale software projects on the planet are remote only, right? Like you look at yeah, you look at Linux, you look at Kubernetes, you look at a few other these other projects that are quite complex. now they're

Carter (18:18)

That's true, right? Like Linux.

Nathan Toups (18:27)

How they develop is fundamentally different. And you could argue, well, it works in this sense where you have committees and it's not a business with the bottom line and these other things. And I I get that. but it is possible. And I think there's also companies like you know 37 Signals who've very intentionally done this. And so you might have to get creative, and some of these things may not apply directly, but again, I I I like this. Again, this is what I liked about this book about learning DDD is that this I think the final

part of this book, this going into chapter 13 and beyond is like the domain driven design in the real world, right? Now we're getting into all the messy parts where it really is I guess we we can go right into it. So in in chapter 13 he talks about how, hey, you know, you might look at this and go, cool, I'm gonna greenfield a project and finally get to use DDD, right? I can finally build it the right way from the ground up, but that most of our career we're gonna have brownfill stuff, right? We're gonna have to

Carter (19:05)

Right, right.

Right, right.

Nathan Toups (19:27)

modernize it's just gonna be some modernization effort there's going to be these other things and that we actually have to use these tools to say hey look we're not thinking about this properly we haven't modeled this properly and we need to like modernize this setup and you know and again he he gets back to we sort of like we we repeat vocabulary that he brings up earlier in the book. He talks about the strategic modernization versus tactical modernization and and I think again

If there's any criticisms of DDD or at least misapplications of it, it's really alluring to focus primarily on tactical aspects of DDD. And I think it's, as he warns in the book, and as as as Will Larson has warned with strategic, you know, think that his strategic thinking work as well, is that strategy is so important. You have to do the prerequisites. You have to intentionally know why you're doing the stuff that you're doing. and so you know, like again, modernization is like.

What are the boundaries of my context? And you know, what how do we structure the teams around the stuff that we're doing before you get into, okay, let's implement, you know, this domain model using this, you know, you know, here's the core versus subdomain and you know, implementation of that stuff. And yeah, I I think this chapter was really interesting too, because they also I think I thought about you and like what you had just talked about.

with the selling D D side actually of like you know, the the sales is actually like a part of our job in a lot of ways, especially when you become like a thought leader in the company. yeah. What what was your what did you think about this chapter, I guess. I I I I'd be interested in especially 'cause y'all have been doing modernization efforts in in your company.

Carter (21:05)

Right, right.

Yes, yes.

I that's listeners of the podcast are familiar with the the ongoing lore of the the the the migration effort my company right now. And I am pleased to say it ends this week. We I know, right? We have yesterday we ripped out every GraphQL request. we now have complete parity in the new rest system. It's actually funny we cause we've just been monitoring our metrics, like okay, you know, let's let's find out

Nathan Toups (21:29)

Amazing.

Carter (21:46)

Like GraphQL, that's the funny. GraphQL makes it really easy to replace itself because in GraphQL, when you're like monitoring like your telemetry, in REST, you get like endpoint metrics, right? Like this many people are calling this endpoint. But in GraphQL, every operation is named. And so it's actually really easy to tell who's calling you because it's just the name of the operation. and so yeah, it was easy to kind of hunt them down or remove them. but there's one that's still

getting called like every now and again. And we're what is going on with this? Like you were I was talking to our engineers. I'm like, you remove this, right? Like, yeah. And I said, I'm like, is this operation like is it pulled? Like it does this get get called every five minutes or something from the web page? And they looked like, yeah, it does. I'm like, okay, this is a user who left their tab open. Right. Like and they haven't refreshed the website. Once they refresh the website, this all go away. anyhow. yeah. So

We're we're doing modernization efforts. It's interesting with here that we we didn't actually in the need to modernize, it was very much like a tech modernization effort and not like a like the system actually was built in a like I don't know if we could call it domain driven way, but like the code modeled what the business was doing pretty well. Like we didn't have to sit down and think like, okay.

You know, we have coaches and we have customers, and these customers a book. And so how do you model that? Because in the old system, we called coaches look-did-doos and we called customers who'sy what's and you know, just like there wasn't anything like that. Like it all made sense. It just like technically the foundations were not strong nearly strong enough. but I I I think I appreciate that about my company is we're all we're all talking the same language, us and we actually

You know, try to we we we refuse to use the terms like the business, like the business wants this. Cause like we we say, like, we're the business, right? But like we use the terms like product and ops use. And so yeah, yeah, I like reading this, it's like I agree. I agree one hundred percent with all of this. And then sometimes I'm a little like, I don't know any other way to build software. I don't know how you would build software and not.

Nathan Toups (24:07)

Right.

Carter (24:10)

Just model the real world. maybe that's more of a a problem if you're like more in the weeds of your project. I I don't know.

Nathan Toups (24:20)

I have

a feeling, so no, I I think you're right. First of all, I I think this is an argument for aesthetics, right? And so if you've learned if you studied under Leonardo da Vinci or Michelangelo or someone like this, you might ha really struggle to be like, I don't know how you don't you know, create a sculpture that looks like a human being with, you know, proper form. wow, there you go. But what I mean is that like, you know, if you're in a strong school of thought that has been effective, I think you do kind of get that.

Carter (24:27)

Right.

I've been called the Da Vinci of software development before.

Nathan Toups (24:51)

the curse of knowledge where you forget what it's like to not understand how to detangle things in a very natural way. I do think what'll happen is and what we've seen in books like Team Topologies, and I will say again, what I'll kind of it's not a critique of DDD per se, but I think that like some of the tools in here are very like object oriented programming oriented, even in how you think about a company, like encapsulation and there's all these things that are happening and you're kind of protecting yourself by

you know, encapsulating complexity where I think that or optimizing for flow in sort of this more functional programming sort of paradigm where I can say, hey, well what if I can actually think about this object's lifecycle end to end and we're now thinking about things like team topologies, where we build teams around some shipping unit, where we ship something optimized for how quickly we can ship updates to that thing.

without having to coordinate across other teams. And DDD has a lot of these ideas, but the way that they think about modeling the whole universe is different. I think that that's where things get where like, that's not how DDD would do this. I don't necessarily think that that's always it, it really depends on your organization. Like if your organization is a very encapsulation, object-oriented sort of way of thinking of the world. But if you're thinking about like user onboarding flows, like I would imagine at your company, you're there's a coaching onboarding flow.

Right. I have a new coach. They've been vetted. They join. We're trying to get them to do this many events. They're trying to we want them to make as much money as possible because then we make money. And then the other side of this is that you're like, well, I want coaches to join too. And I want them to like find the coaches and you know get as most valuable. And those are, you know, very distinct flows and really kind of I would imagine two different platforms in one, right? They they deeply interact with each other, but you really can think of the lifecycle of you can imagine if when your company has

Carter (26:17)

Right, right.

Right, right.

Right, right.

Nathan Toups (26:46)

50 engineers, right? Or a hundred engineers, there's probably going to be engineering parts of your organization that all they think about is customer onboarding flow stuff. Let never touch the coaching side of it other than there's a contract that says when this event happens, we send this thing off to the coaching piece and the coach needs to come back. And you can imagine in which you're not changing how you've modeled the universe, but you have changed the responsibilities that a team

Carter (26:55)

Right, right.

Nathan Toups (27:15)

has to keep in their mind, right? They like I just yeah, I'm I'm on the, you know, I'm on the customer team. We don't I have no idea maybe how the coaching platform functions. I just know how do we keep our customers happy, how do we keep them engaged, how do we make it as easy as possible to query the coaching system. You know, like and so I think those things will change regardless of how you think about the company. Right. Is that and so that's where I do think the D D is really

Carter (27:17)

Right.

Right, right.

Nathan Toups (27:42)

useful, but this also gets us into again, teen topologies, Wardly maps, which are not brought up in this book at all, by the way. And I actually think to its detriment that like Wardly maps are n are this beautiful way of thinking about what's a high value thing, what's a commodity thing. You could imagine that like a update to this book that uses Wardly mapping would actually be better for DDD. and so I I do like that there's these different schools of thought of like how do I build something strategically?

How do I tacally deal this? How do I talk to the business? Like these themes are super important. and so I I think it's been cool to read this book and like now I have a better understanding of somebody who's maybe like a DDD maximalist. And then also can be like, yeah, that's a cool idea. We should absolutely do event storming. We're also gonna write a worldly map because I think that our CEO would understand why we're fixated on this like subcomponent.

Because it directly impacts this thing that's the bottom line, right? Like it and that's this part of the book doesn't get into that as much, right? you know, like w why should we strategically self-host an LLM inference versus using something off the shelf, right? Like that's like a big tac tactical, technical decision that we really should be able to defend to you know, to the business.

Carter (28:43)

Right, right.

Well, and we've talked about this on the podcast before, but this idea that like you're you can't be above selling yourself, right? Yeah there there's a type of engineer, you know, I I think I saw I was like on the experience dev subreddit basically saying, like, how do I become a staff engineer without playing politics? And someone's like, What do you mean playing politics? And they basically described like working on impactful stuff and and

driving direction and talking with other teams. They're like, well, well, that's what a staff engineer does. Like that's the whole point of the job. and so, yeah, like you need to be able to sell a vision. I mean, the whole fundamentals of software architecture, you know, like the that the last third of that book is devoted not even to architecture anymore, but to like how do you sell your architectural vision? and I think you're totally right, which is

Like it's it's easier to do that if you're thinking in like a domain-driven design way, because you know, like every engineer just wants to get in the weeds of of the technical details. And I found myself wanting to do that more. We do monthly demo days where we demo to the whole company. And my demo is always like some metric, right? Like I'm I'm always like showing off some metric or some new technology we use, but then I'm always trying to like

Tell the story of like, this is why this is important. This is why this impacts this part of the business is gonna give us this thing. but but you have to develop that skill. I know too many engineers just want to be like latency is down. And and like you forget that like non-software people, like, like what is latency? What what what do you even mean by that? and so rather if you're saying, hey, the coach page loads.

Nathan Toups (30:47)

Mm.

Carter (30:53)

Three times faster these days. Like, hey, you know, that's yeah, it's not exactly domain-driven design, but but it's adjacent to that idea of like you need to talk in the way that the rest of your business talks. You're not, you're not cooler or better than everyone else because you, you know, can talk in fancy tech terms. yeah.

Nathan Toups (31:10)

man. Yeah, I I recently

had an interaction with some like a guy who's like an economist. He's like a PhD, super smart guy. But the way he talks down to folks that are not in his domain, it was a good reminder of meaning like I should never ever even get close to doing this in my domain. yeah. One time he was he he said something like, it's like a brain surgeon trying to talk to a paramedic or something. And I like, this is even if you're correct, like there's a different way that you could be

Carter (31:24)

Right, right.

Yeah. Yeah.

Yeah, right. I'm like,

Nathan Toups (31:40)

Yeah. so yeah, this rounded out the the part three of the book and this is where I think again, this is where the sort of like messy implementation stuff gets in, and I think this is gonna be a contentious topic. Chapter 14 is two things. Number one, it's all about microservices. And number two, he calls the patron saint John Osterhout on his deep modules. And is you know if you remember back all the way to like

Carter (31:52)

Right.

Yeah.

There we go.

He does.

Nathan Toups (32:09)

I think it was the intro for the first episode on this series. I'm like, what would Osterhout do? Right. Like I was like thinking about this. And then he literally brings up Osterhout and Philosophy of Software Design. And I think it's interesting. Like I understand where the thinking behind the microservices and DDD comes. I think that maybe some of the most unholy decisions around modularizing too much.

Carter (32:14)

Yeah.

Right.

Nathan Toups (32:37)

Is is directly from the best of intentions with a DDD take without understanding the deeper piece to this. And I I think that this book actually does a good job of being like, don't go crazy. Like if you take this to its li if logical smallest component, you're basically gonna be doing like function as a microservice. And that's like a horrible thing. Horrible thing. And I loved it. It was like a very much.

Carter (33:03)

Someone's done

it.

Nathan Toups (33:04)

Yes, it's a steel man argument, right? It's it's this idea of like, hey, well, if it if that's good, then why don't we break it down even more, break it down even more? and so I really appreciate he did advocate for the deep modules, which again, for the uninitiated, if you if you want to go back, Osterhout says, Hey, if your abstraction is very shallow, where you have like let's say object with a bajillion methods that you can literally interact with every piece of the inner state, that you're really not abstracting anything, right?

Carter (33:31)

Right,

right.

Nathan Toups (33:32)

If you're

exposing everything to the to the to the caller, then you're really not making any decisions. You haven't decided how this thing behaves. That it's much better to have a much smaller it set of interfaces and go deep, allowing a lot of decisions to happen inside the inner workings and expose something that's like much simpler to the outside. these can be super powerful because it allows you to like change the implementation and do these things. and that actually these are a a

Excellent way of thinking about what is a microservice. and yeah, again, I I thought this framing was really nice. I still think it's tricky because I think, and this is DDD in in general to me, it's very easy to misinterpret DDD and then get in a big holy war on what the actual interpretation of DDD is, which I think is actually not great. you know, if if all of us read this book.

And then try to implement something and then we're all confused as to the in interpretation of it. I think that there's like something missing. That maybe it's aesthetics, but I don't know. Wha what was your thought about this section?

Carter (34:37)

Well, I do I do love a good holy war about whether it's in football, that's for for the uninitiated, that is the the name for the rivalry between my alma mater, BYU and and Utah, the state school. It's the holy war. yeah, yeah. because there's there's a whole I died I man, the holy war in Utah is insane.

Nathan Toups (34:40)

Ha ha ha.

really? Okay, there you go. So you really do like a good holy war.

Carter (35:02)

Right. Like it you can feel it in the air like the week before the game. and everyone is so stink intense. it's awesome. Anyhow, what was I gonna say? No, no, that yeah, I microservices are so contentious. I I love this idea, like Osterhote says this idea, like if you're if your modules are super shallow, then you're you're not abstracting anything. It's like, did you ever watch community?

Nathan Toups (35:27)

I've seen bits and pieces. yeah.

Carter (35:28)

Bits and pieces. There, there's

like a they do like parody episodes and like one that's like a parody of like conspiracy theory movies, right? And like at the end they're doing like the reveal of like who's been conspiring with who, but it it gets revealed that the dean has like he's both he's teamed up with two of the characters against each other, right? And so like he's but like and so like the two characters find out and then like team up with him themselves against the dean, and and they're like, they're like, Do you even know what a conspiracy is? Like if you just

team up with anyone who suggests it, you're not having cons you're not even conspiring against anyone. You're just doing random crap for fun. And so when you're talking about like you're not even abstracting anything, I I had that thought. yeah, I mean

Ugh. I I like, yeah, he talks a lot about like sizing here, which is like, okay, if you're gonna make a microservice, how do you size it? And like it's this is so much where like taste and judgment and aesthetic comes into play, which are very hot topics in an LLM world, right? Because how do you know what is the right size of a microservice? And

Nathan Toups (36:19)

Right.

Carter (36:40)

I mean, I would argue these days that like I I I think a microservice, I think it only makes sense when thinking about it from a team perspective. I don't think there is any good technological argument. Well, I won't say that. There's not there are very few good technological arguments for microservices outside of like this one specific part of our service is incredible.

Incredibly spiky and will need to handle anywhere from like zero to 10,000 RPS and need to like or or or let's say like maybe the opposite, kind of like we know that this 70% of our system needs to handle 10 RPS, and this part of our system needs to handle 10,000 RPS, right? And we don't want to have them intermingle. Like maybe there's a technical argument there for like these should be two microservices in general. I've said this before.

I think microservices are a team problem. I I'm a big fan of the idea of like, I hate when multiple teams are working on the same monolith, and then it's like you you have to do like these GitHub things where like you have like the code owner's file. And it's like if you're modifying this part of the code, you need reviews from these people. But if you're modifying this part of the code, you need reviews from these people. And then you have whole teams that just like fundamentally don't understand how the application is built and deployed, which I hate. Like I think there's something to be said for.

Nathan Toups (38:06)

Right.

Carter (38:08)

complete ownership end to end of what you're working on. But I also understand like re-orgs make that tough because then it's like, okay, if you I mean, what it's Conway's Law, right? Conway's Law, which is just that like your technology is just going to resemble your org chart. And so if you redo the org chart and then you're left with these microservices, like unless you can port an entire microservice cleanly to another team, you're gonna be left with like

Nathan Toups (38:19)

Yep.

Carter (38:35)

Yeah, now you just have microservices, but you have like half teams working on all of them. Yeah. Yeah.

Nathan Toups (38:37)

I right. I think

to me, yeah, I I agree. There's two there's two parts to this. Number one is it it really I do am I in the same belief that most microservices are an optimization towards organization structure, in that no, not at all. Not at all. The other part of it though is that the other part of it is that like

Carter (38:53)

Right. Which is not a bad thing. Yeah.

Nathan Toups (39:02)

I've definitely seen stuff go way too far. And a lot of it gets super tangled up. And and he talks about this. You you basically make this distributed big ball of mud. and I'll tell you the couple of areas of code smell that that have come up and just things that I've seen in the industry, things that I've been doing, these discovery audits, subcontracting as at another company where I get to like look into organizations and help them. Like this is a company that does managed Kubernetes, so obviously they

Carter (39:10)

Yes.

Interesting.

Nathan Toups (39:29)

Are a big advocate for you know microservices or you know service-oriented architecture type work. But a lot of that's their business. Like they basically, yeah, and there's a lot of workloads that make sense. Like if you're doing bursty sort of ML flow ETL pipeline stuff, if you're doing web services where you need to have good horizontal scaling and really nice trunk-based development, if you use the Kubernetes stack and you have folks that are domain experts in understanding it,

Carter (39:35)

Wait, that that's their business is managed Kubernetes? Okay, okay.

Nathan Toups (39:58)

So that the engineers can just write code and it just deploys magically. That's a pretty cool setup, right? Kubernetes itself can be a crazy beast and you can do a lot of stuff. That's really awful. But Kubernetes, when it runs well, you really do reduce cognitive load on the teams. and this is where I think that microservices can be really nice, is that if you have teams in which you're spinning up new experiments, you have new services, you really think about aspects of the company and you really want

them to be able to have their own deployment lifecycle. what happens though is that your CI CD pipeline becomes super complex, right? To make it simple for the engineer, your CI CD pipeline actually has to be like really well thought out, abstracted in a way that it can kind of handle a bunch of different things. And where you kind of get bent up and backwards, and we we saw this in software architecture, the hard parts and these other things that come up, is that let's say you do break up out a bunch of microservices, but you'd also decided you want to have

Carter (40:34)

Right, right.

Nathan Toups (40:56)

you know, Acme Co lib for your Python. And you really what you wanted to have is that your your your common lib is this library that is all the common modules to make sure that all the teams are doing things the right way. They have the right schema files. They're doing these things, but they also have like 20 repos. And now all these 20 repos have a dependency on this like common library that's your Python library. And then all of a sudden now you're in this diamond dependency hell.

Carter (41:19)

Right.

Nathan Toups (41:24)

Where each of them are now having to think about what's their upgrade path for the common library that you've written. you know, there's all these like weird forms of coupling that you can kind of get tangled up in. You've really violated DED in this way. and so I do think that like if you're gonna really do microservices, you really need to think about are you truly decoupling aspects of your process, right?

Carter (41:47)

Right.

Nathan Toups (41:49)

is it okay that we actually implement the same thing a couple of different ways across teams to reduce coupling, which I think in a lot of cases is true. if you are gonna couple for let's say telemetry, let's say we all want to ship to Datadog, well, really I should not even expose that to the engineering team, right? Really we should say, you're gonna log everything to standard out, or you're gonna use this SDK that doesn't change very often. and we're going to use a sidecar, we're gonna use, you know.

Carter (42:10)

Right, right.

Nathan Toups (42:17)

EBPF or something and then like ship these things off in some common pattern. those are all decisions that you have to make as an organization that again, if we go in and try to split up everything into microservices and yet we're spending a tremendous amount of time coordinating how we do stuff, you you you're broken. Like you really should probably be a monolith because operationally you are a monolith, right? You you are doing one thing.

Carter (42:39)

Right.

Well, I think microservices are probably one of the biggest victims of like cargo culting in the industry.

Right. Because I I I I really like how you said it. Like the the idea you need to be coordinating with microservices is like crazy. Right. And I remember this in when I worked at one of the food delivery companies and like to set up our just to get our our local application running, we had to like like

Nathan Toups (42:50)

Yeah.

Carter (43:10)

We had one senior engineer and he knew how to do it. There was this we had like this like internal utility, like Docker utility that was designed to like pull everything down and and run it all. And and yeah, and and just like you kind of think, like, you know, I was too young. I was just like, this is how it works. This is what you do, right? but yeah, looking back, I'm like, no, that was the distributed monolith, right? Because like

Because like I was pulling down services that like we didn't own, right? Like and I but I had to be running those services just to run my one service. Like to run my one service, I had to run four others, right? And so you got to take a step back and think, like, okay, well, wait a minute. Could we have some staging environment that you can just automatically connect to? Like that's probably step one. Step two is like probably mocking at the very least, right? Like, can we?

Nathan Toups (43:42)

Right.

Yep.

Carter (44:04)

Can just be mocking out the calls to these things? But even then, the more you kind of get into it. But then like, is that just microservices? The idea you could just have a microservice that functions entirely on its own. Cause like the idea with the microservices is like that there's gonna be the user's microservice, right? And you know, pretty much every other application is gonna have a dependency on it. And so I don't know, like, is that is that just how microservices work?

Nathan Toups (44:28)

Yeah, and it this

gets into really crazy stuff where like I I was in a school of thought where everything should happen over the event bus. And so you really shouldn't have a microservice calling another microservice directly. I we always tried to do what I called we called like local first development, which is a little different than local first where all the state of a machine is or your application is local. But local first development for us was I should be able to spin up a dev environment with no external dependencies.

So if we did require, let's say, this service to have these three other microservices, if that had to happen, the s the platform team should provision a way to make that as like painless as possible, right? Like it it handled bootstrapping the state of whatever things are in place. But we tried to as much as possible make it so that you could run your service independently and then just events over the feed are how it talks to each other.

But this is where I think things can get super complicated. I've also been in environments where we did really crazy stuff, like using we were in an Istio environment. Istio is like a is like a service mesh topology, which again in the heyday of microservices was very very common. And I could actually be in a dev environment with all of the services and then make a virtual service with a bunch of routing for my version. So basically

Carter (45:51)

That's cool.

Nathan Toups (45:52)

Yeah, so you could basically have like a JWT token that had a claim that said use Alpha V3 or something. And Istio can route my service within the cluster of microservices within the larger topology. It's pretty complex. I mean, like talking about this is not trivial, but we made it so that you could just like annotate this thing. It would run locally on your machine and then actually could talk to the remote cluster as if it was in the normal cluster.

Carter (46:05)

Thank you.

nice.

Nathan Toups (46:23)

again, we had heavy Kubernetes chops. It was very it was not hard for us to do. There's a lot of critique of like, is Istio even the right way of solving the problem and all these other things? but we were very comfortable with it and it our team felt very productive. but we also really worked hard to reduce the dependency of one service to another, right? Like we really tried to make sure that our services were encapsulated as much as possible. We had strict database per service, you know.

Carter (46:44)

Right.

Nathan Toups (46:52)

things going on that we we we did a bunch of like we did a bunch of extra stuff too that I thought was kind of interesting. for instance, we had a bunch of services for this trading platform that we had internally. And the team that owned the API for that service also controlled the SDK and we had Python SDKs for all of the services. What was kind of cool about this is that our data scientists who used these

These API endpoints, they never thought about the API endpoint. All they thought about was the Python SDK. And what was what was neat about this is that we could change the API as long as we didn't break the SDK preemptively. So like we would actually like roll out version, new versions of the API not breaking the SDK, and the SDK would always be backwards compatible. So let's say we had a V1 of the user's route or something, and we wanted a V2, we could deploy V2, we could start testing it.

Carter (47:26)

Okay, nice.

Nathan Toups (47:49)

even in production. And then when we wanted to r release this, we would like update the SDK saying, hey, here's the new user's V2. It's backwards compatible. You can just use it. and they didn't even they didn't even care. Like it was just this. But we controlled the whole pipeline. And so it it kind of gave us this like in the same way that your service controls the schema for the data store behind it, by controlling the SDK, we were able to

control their perception of the API, which then we controlled the data store underneath it. And again, we had full control of that internally. We had, we had a full control of the tool stack. And we really thought from again, from like a DDD standpoint, our customer was the data scientist. The data scientist making new models that could trade, you know, hundreds of millions of dollars on our platform was like that was the, you know, if we failed in delivery of that, we failed.

Carter (48:34)

Right.

Nathan Toups (48:44)

as an engineering organization. and so it made it really clear for us of like who owned what and how do we introduce changes through the through the system. And it gave us very deep modules, right? It gave us like a r this really sort of natural way of we it was very easy to figure out which team owned what and where the service boundaries were and you know, and how we maintained these things.

Carter (49:08)

Well, we've only got a couple of minutes left before we gotta wrap up. Is there anything else left in the book that you wanted to talk about?

Nathan Toups (49:14)

Yeah.

So there's two chapters. We'll kind of speed run these. I we really have to hit event driven architecture because again, we got we got roasted, namely me. The last one was also data mesh, which again, kind of cool, but I we don't have to get that into that one too much. but he taught he kind of talks about how does DDD fit into this new paradigm, which I actually thought was a really cool framing. just me personally. So event-driven architecture, and this is where I made a mess of things, and I think I've actually made this mistake in production.

Carter (49:19)

Yeah. 'Cause

Yeah.

Nathan Toups (49:43)

you know where I was actually thinking about what events I emit at the wrong layer. And I will say the DDD framing here is excellent. he talks about the taxonomy of what does work. So first of all, event driven architecture is this idea that we do these asynchronous events. I try not to talk, I try not to go and query my other microservices, but instead I say, you know, the user has onboarded

Step five or whatever, right? I maybe omit to this event. And then any other part of my microservice architecture that cares about that the user successfully gets through step five of the onboarding process can react to this, right? They can it can do its thing. And he talks about domain events. these are the events inside of the domain that are in very important. If we're thinking about a d event sourcing pattern, the domain events are literally every event source thing that I can replay from from.

From square one. And then he also talks about event notifications. Event notifications are an event between producer and consumer, right? So this would be what an A Kafka event would be, right? If we're gonna think about this or or SQS or whatever tools you're using, RabbitMQ, event notification. And that these are less detailed, and they basically say, Hey, something happened if you care, right? Like that's the sort of idea. and then there's also this idea of like an event carried state transfer, which he doesn't get into too crazy, but it's this idea that like,

Carter (50:51)

huh.

Nathan Toups (51:11)

Typically, when I have an event notification, it's really an invitation for that person who cares to go and ask for more details. Like, user onboarded. And then I go, cool. I really care about this. Which you, you know, like here's the, you know, the user ID. Tell me all the details of the thing. And you query the service and you get the information and, you know, whatever that comes out of it. an event carried state transfer is where actually.

When I broadcast this information, I might include all the information that I think others would care about. So I don't have to do a second, you know, query afterwards. and he brings up this thing, he goes, Hey, you might think that event sourcing and event driven architecture are one and the same. And you're wrong. he's like, he's like, if you publish domain events, remember domain events are the things that are important for event sourcing. If you broadcast this out, it leaks the internal model.

Carter (51:53)

Yeah.

Nathan Toups (52:05)

In that you're really breaking the idea of what event sourcing is all about. Event sourcing is literally about I'm not mutating state in my database. I'm doing this append only record where I can, no matter what happens, I can go back and play back and you know, sort of materialize or or hydrate the current state of the system. Right. There's there's nothing about the network boundary, everything is internal to the state of this domain. And all of this stuff is really like a domain oriented piece.

Carter (52:24)

Right, right.

Nathan Toups (52:35)

That is the the thing that I mixed up is that I was like talking about domain events and event notifications and mixing these things up in a way that was quite confusing. I think we again we got called out that I was kind of like blurring the lines here. And and so yeah, that was yeah, I I hadn't thought about keeping that clear boundary between the two in a strictest sense. I think to my detriment in the past.

Carter (53:00)

Right. Well, I mean, it's I think it's tough. Like, I I you know, I I learned a lot reading this book. and yeah, right. And and just this idea that, like, yeah, there are those two different kinds of events. and yeah, I think I don't know, I I'm very, very interested because we're doing more event driven architecture stuff right now. It's very simple at this point. but I've said since the beginning of the migration, like, hey.

Nathan Toups (53:08)

Right.

Carter (53:29)

There's a part that's gonna bite us, it's gonna be this right here, because we we aren't super clear on how this works exactly. Or I mean, nah, that's that makes us sound like we don't know what we're doing. We kind of know what we're doing, right? But it's a little like we are less familiar with the failure modes here, right? And there's gonna be just some failure mode. it's been interesting with this whole migration learning about all those failure modes, right? Where like

You know, we we got off Mongo, which we're all very grateful for, and but on on our new Postgres database, like we've had moments where we're like brushing up against the CPU limit. I'm like, yeah, that didn't happen on Mongo. Like, you know, Mongo kind of took whatever we we threw at it for the most part, right? yeah, I think I I like the idea that in a with bounded contexts and domain driven design.

Events are the mechanism for you to communicate with each other. And one thing I really like about event-driven architecture is how it lets your services be kind of dumb. I say that all the time, like especially at our front end. I say, like, our front end is too smart. It knows too much about the back end. It knows too much about how the rest of the system operates and has to be like a partner in doing that. Like our front end should be displaying things.

Our front end should get data back and should be very opinionated on how it displays that data to the user, but it shouldn't have to know. I need to format this data in such a way in order to, you know, or like we we do some dumb things. Like there's some like scheduling logic in the front end. Like the front end knows that after this thing happens, it needs to then schedule the meeting between the client and the coach. And like the front end shouldn't know this.

The front end should know that like it needs to complete the order, and then all of the side effects of the order being completed should happen in the back end. That we shouldn't have to talk back to the front end and say order is completed. And then it says, okay, now that order is completed, I will go schedule, right? Like it's a you know, and and so if you're gonna go like that, that's a more technical boundary, right? Like this is the front end versus the back end, but in a bounded context way, you know, like.

Nathan Toups (55:43)

Right.

Carter (55:48)

The order service shouldn't need to really know anything about the user service, right? It shouldn't need to know about any of the internal details. And so to avoid like this kind of handoff between the two, where again, you're building kind of the distributed monolith, I like the event pattern. I like the event pattern of like, hey, I'm just gonna tell the world something happened and anyone who's interested in it can act on it however they want. I don't care. It's it's out of my hands.

Nathan Toups (56:14)

Yeah. And and I think that's the, you know, if your system tolerates eventual consistency, right? This is a really interesting thing, which is that, hey, within this acceptable time window, if these events emitted can be consumed and then dealt with, you know, you you end up getting these really nice pieces. I think another thing that they talk about in this sort of event-driven architecture piece is that if you think about event-driven architecture versus event sourcing, and you're like, which things do I communicate out to the rest of the world?

Carter (56:19)

Right, right.

Nathan Toups (56:42)

You know, it says, look, you actually get this really clean contract, right? The the whole point of this is that you should have this bounded context should tell you what events should cross the boundary, right? You really can you can be the the person who you know is TMI. You like don't want to be that. Don't don't let your bounded context be given TMI. like

Carter (57:05)

Yeah.

Nathan Toups (57:09)

Too much information is ends up being bad. And and they talk about this because you know y your system will be used in surprising ways. What what is it is it it's it starts with an H. Is it h hip Harlow's law? I can't remember. Harlow's law. People are gonna roast me on this one. it's the one that's like any way that a system could be used will be used. I can't remember. Yeah, I'm gonna it's

Carter (57:33)

Right, right. I there's like a famous X K C D on like you don't know.

Nathan Toups (57:39)

It anyway, there is one which is like, yeah, look, if in you should think about this, every event that your system emits is potentially going to be a dependency on a potential coupling to another system in the future, right? If you just kind of ad hoc say, hey, look, any interesting thing that happens from our event sourcing pattern, we're just going to emit this because who knows, maybe we'll need it externally one day. this chapter really says that is really bad idea, right?

You can get what's called temporal coupling, right? Like it really becomes really important when something happens exactly. You can end up getting you can end up having real really hard time troubleshooting asynchronous flows because again, maybe you know, there's a five-step process, but really you only want the other systems to know when you've completed something in the internal state machine at the very end. But somebody with the best of intentions thinks like, well, when step three of five

hits actually I want to like get my service up and running really fast. So like when three hits, I'm gonna go and react to this thing. But really there's a potential that you could roll back the whole transaction by the end of step five in your sort of internal state. And you unless that person has all also created an event response to the rollback, you're in a lot of problems, right? And so like this is where things can get and I and I look at this now and I go, okay, I understand why people kind of

Carter (58:52)

Right.

Right, right.

Nathan Toups (59:06)

the wiser DDD folks kind of really, you know, bristled at what I was saying. is because like I was I was sloppy in my thinking on these contracts. And and it could be that aesthetically I kind of naturally think about this and I didn't really think of why. and maybe I have an aesthetic or a taste that kind of thinks about these in these contract-oriented ways because I've talked about this. but

I won't think I was deliberate and I don't think I ever I've never given someone feedback that we're emitting too many events, right? Which which is a smell, right? It's a smell too that we're probably we're emitting too many events.

Carter (59:40)

Right, right. Right, right.

Yeah, well I so I guess yeah, you know, I

That is interesting to think about because there's a part of me that wants to be like, that's your problem. You know, I'm just telling you things. And if you want to listen to them, you know, it's like in The Simpsons, like Bartleys are fighting and their but their mom says like to stop fighting. And they're like, Okay, well, I'm just gonna swing my arms through the air while walking towards you. And if you get hit, it's your own fault, right? Like that's how I feel about, you know, publishing all these events.

Nathan Toups (1:00:13)

Wow.

Carter (1:00:19)

But yeah, there is something to be said about like intelligently designing your events because like I I guess if you admit an event to the world, again, it's it's like that smell you're talking about, that that anti pattern. It's like you're emitting these events to the world. And then if some team came to you and just like, hey, well, wait a minute, like you this event, like you're talking about step three of five, we're listening to that. And if you tell them like, well, don't listen to that, they're gonna be like, Then why did you emit it? Right. Like by admitting an event to the world, you are telling the rest of the world you can rely on this.

This is information, you know, that you can use to kind of govern your workflows. And that's interesting. Yeah, you know. I'm I'm I'm you know what? I'm we're let's jump ahead. Let's jump ahead to what we're gonna do differently this in our career. I'm gonna say that I'm gonna say that. I'm gonna say that that we're probably admitting too many events. Doesn't matter right now because we're one team, but in the future, that could that could be a problem. So I'm gonna be more careful about all the events we admit. Although I remember reading that like it was good.

Nathan Toups (1:00:59)

Yeah, we gotta wrap it up.

Carter (1:01:14)

To omit an event, even if you thought no one would subscribe to it, which I took to kind of mean like you should be like event emitting happy, but maybe implicit in that advice is this domain driven design approach of like only omit an event if you are confident that it can be relied on. yeah.

Nathan Toups (1:01:34)

I think that's the thing. I would admit the

event if you think it v it's a valid notification that would come out on the contract. But you say people could be interested in this. And again, it depends on I think this is really where like if you're not doing event sourcing internally, when you decide aesthetically to innovate an event is probably a pretty good thing. Event sourcing is its own beast, right? We're we're really talking about the fact that if I play back from epoch of all things that are happening, I can re

Carter (1:01:43)

Right, right.

Nathan Toups (1:02:03)

you know, hydrate the current state of something with zero deletes. I see exactly everything that happened. those things are internal to the domain. And all of those little state machine changes are not interesting to the rest of the business, right? Those are way too much information. and so and anyway, yeah. for me, I think I really want I have a there's an area with one of my clients where I think event storming would be.

Carter (1:02:08)

Right, right.

Right, right.

Nathan Toups (1:02:32)

Helpful. We're in the middle of a modernization effort. I think that it's a making us rethink the boundaries of some of the work that's been done. And that I think having the domain experts in the room calling the shots on is our assessment correct or not really valuable. And so I I think I'm going to we're gonna try an event storming exercise remotely. but you know, so we'll see. it's impossible. Well, yeah, we'll see. Maybe I'll crash and burn.

Carter (1:02:51)

Right. Right.

You can't do it, Nathan. It's all gonna collapse in on itself. That's impossible.

Nathan Toups (1:03:02)

So

Carter (1:03:04)

no what? I I believe in you. I think I think Vlad, I think, is a smart guy. But on that, get with the times, Vlad. Get a whole pandemic. all right. okay, fantastic. As far as who'd recommend the book to, last week I said just those wanting to explore more sophisticated ways of constructing software. And if you struggle understand like the business when building software, like this is a great

It it's a good book. It's a introduction to domain driven design. How about you, Nathan?

Nathan Toups (1:03:31)

Yeah, it it is. I I I'm in the same boat, like s you know, senior lit engineers leadership, especially if there's someone in your team that's really been hounding the D D approach. I do think I will say, if you listen to some of the other stuff, like if you read team topologies, if you re read Will Larson's book on strategic thinking and engineering, you get the best ideas that are in the D D D work.

that would positively impact your organization if that's the part that you're struggling with. If you're struggling with translating this into sort of the technical implementation and thinking about where the boundaries should be, D D this book is a great way to start, right? I think it's a it's a you aren't gonna be led astray. and it might give you some vocabulary and some way to talk to the rest of the organization like the ubiquitous language stuff. That would be super useful.

Carter (1:04:14)

Right.

My manager is very anti book, which I think is very funny. he's well, not really, but he he's like business books in general. He's like, I never read a business book that I liked. I'm like book, yeah. Which I I don't need, I don't need to defend my position. I'm like, you what? I've read a bunch of books and I've learned a lot from the books. So I know I'm correct. All right. put that on the podcast. Put that on a mug that when you heat it up, renders the text. I've read a lot of books, so I know I'm correct.

Nathan Toups (1:04:34)

He's like, Book overflow, what are you doing?

Carter (1:04:56)

All right. thanks for tuning in, everyone. we're gonna this is we're gonna take a brief break with the books. because next week is gonna be our two year anniversary episode. We got a fun little exercise planned. We're excited about it. and then we're gonna go we're not gonna go dark for a few weeks. I'll be on paternity leave, but we have we got plans in the work for some special episodes. so you'll be hearing from us.

And yeah, but you can always find us on Twitter at Book Overflow Pod. I'm on Twitter at Carter Morgan. You can contact us at contact at bookoverflow.io. You can find Nathan his work with his consulting agency, RojoRobato at rojo roboto.com. All right. Thanks, folks. We'll see you later.

Nathan Toups (1:05:37)

Yeah.