I was reading a lot of this book sort of adversarially being like, what would Osterhout think about these things? And I will say that I think in the realm of strategic DDD,

there's actually a lot of good overlap with philosophy of software design.

Carter Morgan (00:21)

Hey there, this is Book Overflows, the 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 am Carter Morgan and I'm joined here as always by my co-host Nathan Toops. How are you doing, Nathan?

Nathan Toups (00:32)

Doing great. Hey, everybody.

Carter Morgan (00:34)

was just realizing I do that intro at every episode, but we didn't start out with that intro. And I don't really want to go back and listen to all of our early ones, but like it'd be intro. Like when did we lock in on that? When did we lock in on that and doing great? Hey everybody, go do it. There we go. Well, thanks for joining the podcast everyone. I always like comment, subscribe, join the discord, book time with us on Leland. All those links are in the episode description.

Nathan Toups (00:47)

That's a great question. I'm going to have to go check it out now. So I'll report back next episode.

Carter Morgan (01:04)

we're excited this week. This is, we had said we were going to do this one and then we actually took a break to read mythical man month. And I'm actually really glad we did because I think a lot of what's in this book kind of dovetails nicely with mythical man month and with a lot of thoughts I've had lately about software engineering in general. and yeah, that's why we got learning domain driven design by Vlad. Can none of, I think that's how you say it. K H O N O N O V. So a couple of O's in there.

Vlad Kononov is a software engineer with over 20 years of industry experience during which he has worked for companies large and small and roles ranging from webmaster to chief architect. When's the last time you've heard of someone being a webmaster?

Nathan Toups (01:48)

old school.

Carter Morgan (01:49)

That's old school. Yeah. What would we call a webmaster these days? Just like a lead web engineer. Yeah.

Nathan Toups (01:54)

They kind of were like a jack of all trades. They were kind of like a sysadmin.

I think sysadmin probably replaced it as a title. But you probably just understood how the website worked and I'm sure, you know, probably dealing with CGI bins and Perl scripts and all that kind of fun stuff.

Carter Morgan (02:02)

Yeah, probably.

Yeah, yeah. Well, so we've got a certified gray beard here. 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, untangled legacy systems, and tackle complex architectural challenges. He lives in northern Israel with his wife and an almost reasonable number of cats. And I think reading this author introduction, I hadn't read this before the book, but

This is another book that's like written by a consultant who deals a lot with like legacy, like fortune 500 ish companies. And that makes a lot of sense. Nathan and I were talking about this kind of before the podcast starts, we're going to keep talking about it, but it's a, it's kind of a different style of software. as far as the book and instruction, he says building software is harder than ever. as a developer, you do, you not only have to chase 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. All right. So this book is about 450 pages. How many chapters? I don't know. It's a decent amount of chapters. Uh, I'm looking right now. Um, 16, 16 chapters. So we read the first six. Uh, we're going to make this a three parter.

Nathan Toups (03:24)

Ooh. Yeah, actually I can pull that out.

Yep.

Carter Morgan (03:37)

So we're about a third of the way through this book. Nathan, give me your thoughts on learning domain-driven design.

Nathan Toups (03:42)

Yeah, overall, I think this is a great introduction to DDD. You know, the famous book that started it all was the DDD Evans book. I think they call it the blue book. It arose to me if I'm mis-attributing that. But it's also famously difficult to read and a bit dated. That hasn't scared us off in the past, but I thought that if we were going to ease into proper DDD, this one seemed highly regarded. It's also an O'Reilly book that came out.

within the last five years. So I thought this would be a good place to start. Again, just from an aesthetics standpoint, the pacing is really good. It's solidly written. I really appreciate the way that DDD frames doing work in sort of this business and terminology around things like bounded contexts and...

Carter Morgan (04:22)

Yeah, yeah.

Nathan Toups (04:36)

and sort of ubiquitous language and these other really important things that I think a lot of teams struggle with. And I understand why DDD sort of starts with it and saying like, hey, and we'll get into it. Just like, hey, you can't just like reinvent the wheel and then hope that the rest of the business understands what you're trying to communicate. You have to spend a lot of time making sure that you've included other stakeholders. And I like that aspect of it. Any criticism I have on the book is really sort of like there's aspects of DDD

that I don't love. And it's probably in the same sense of that sort of consulting driven, test driven development, sort of getting into the tactical tornado type of world where I don't think it's DDD's fault itself, but I do think that there's aspects of like what's considered normal that I'm a little apprehensive about. And so it's not anything on the book itself. It's really more on like, do I reach the same philosophical conclusions? And hopefully we can dig into that today.

Carter Morgan (05:33)

Yeah,

I agree a lot on this being very well written. We were joking, like we've been spoiled with the podcast where I think we've done like, it's like five or six episodes in a row where we've had audio books. And so we've been able to get through a decent chunk of the reading this year actually, without actually reading. We've just been listening to the audio books. So this is our first book in a while, but it is written very nicely.

Paced very well, strong voice from the author, succinct, doesn't spend any more time. There was never a part where I'm reading and I'm like, I wish he had talked more about that or kind of the opposite of like, okay, I get it. Let's move on. Very talented author. And this, it does really nicely with what we were talking about with mythical man month last week. And I've just been thinking about this a lot, this idea of like accidental versus essential complexity where

Like all of software engineering, the whole history of it has just been reducing accidental complexity, the problems we cause for ourselves, right? And then there is the essential complexity, which is just the actual hard part of making software because you have to, all software models the real world in some way and choosing how you model the real world is always going to be complex. And so I think

Nathan Toups (06:53)

Great.

Carter Morgan (06:59)

in an LLM world, really what that's doing is eating a lot of that accidental complexity. I think it's chipping away at some of the essential complexity, but more in like a rubber duck thought partner kind of way. And so this whole kind of first third of the book is about this idea of like modeling business domains. And I think that's a really useful exercise as a software engineer because the days of just making your living

and the accidental complexity have, they've shortened. And again, the whole history of the field has been shortening those days. So, you know, get comfortable, get used to this sort of stuff because I think this is where our careers are.

Nathan Toups (07:37)

Right.

Well, and I think

this is also where folks like Jirje and Jirje Oraz and Will Larson have been kind of harping on this for a while. You need to find the essential business value that's happening. They've kind of been pointing people and I think the top sort of engineers sort of intuitively find essential complexity to spend their time in. And I think where we are now, it really just sort of

Carter Morgan (08:07)

Right.

Nathan Toups (08:11)

It's a forcing function to get a lot more things. And I will say, if you try to dial it in, you also run into a lot of problems. think this book, and we'll get into it, there's a tactical portion of DDD and then there's also a strategic portion. And they kind of give this warning over and over again. If you skip strategic DDD, you're going to run into problems. And I would say that that's doubly true now, right? That you really need to spend time on the strategy side.

And again, this is a good through line of talking about Mythical Man Month, talking about Will Larsen's, all of his books kind of get into this stuff as well. And I don't know, it's weird that we're kind of gravitating towards this theme that's been going up. This year has been all about this, right? And I don't know, I'm pretty excited because I think books like this actually become more important as we're writing less code.

just because we need to spend time in that strategy section.

Carter Morgan (09:14)

Yeah. And as we're reading this book, they start getting into some code examples. And I think it's just like you said, Nathan, it's just a different way of writing code. And it's a way of writing code that I've kind of avoided like the plague. Like there's just a type of engineer who works like in that Microsoft stack. It's like C sharp and.net and Azure. And it's very like buttoned up. it's not my jam.

Um, so I don't really play in that, uh, but I don't know, like I've never been, I've never been super interested in like the nitty gritty of code. Like I, I, like, I don't know, like, I like good performant readable code, right? But I, I have always found myself much more concerned with like the higher level decisions, like architectural stuff or

broader patterns throughout the code base or how we're, again, modeling kind of features in the real world. Like people laugh at my company, like I'm a notoriously easy PR reviewer, but I'll have a lot of thoughts about like, yeah, like the data models I'm much more picky about. So.

I don't know, like you read a book like this, which is just like a lot of like, here's how you should write code. Here's how you should write code. Here's how you should write code. And I don't know, like part of me is like, is it because we're in this age of AI that I find myself being a little like, you know, why do we care that much? Or was I always like that?

Nathan Toups (10:57)

Yeah, and I will say that some of these feel like obvious and good code structure, and some of these kind of feel a little contrived to prove a point. And I wouldn't, again, I don't knock the book too hard on it because if the code example doesn't apply to you or if it's not in your coding style, it doesn't meet your aesthetics. Who cares? You can just kind of look at it go, OK, that's the way of doing it. I wouldn't do it that way. And I think that that is something you should develop over time. This book is not about

implement it this way, right? It's really sort of saying, hey, if you see this sort of class with these fields in it, here's the accidental complexity that can come out of it. And I think regardless of the style, it's helpful, right? It's helpful to go, yeah, yeah, we do that. We don't actually have a way of knowing, is this a unique ID for this user class, and how does that model back to what we store in the database, right? Or whatever sort of thing that you kind of run into, right?

yanking something out of a data store and interacting with it with some state machine or, you know, some thing that you're trying to like reason about. And he doesn't get too much into at least in these first six chapters of he'll kind of give a nod to like, this is really easy to model if you can do a transaction, but we're going to get into distributed data, distributed data systems and things like that. And he kind of was like, hey, this is why you'll get tangled up. But I think it's really left to a book like

designing data intensive applications or some of the other books that we've read to kind of get into that, you know, the deeper wise. I think in this case, in the case of DDD, he's really focused on this idea of like, how do I model reality in a way that minimizes trying to boil the ocean or trying to like model everything in perfect at a global scale? Is there a way that we can structure things? And so teams can be independent.

we can work with stakeholders, that we can adapt to changes over time. All the stuff that you kind of think about when we think about evolutionary architectures and these other things, they all kind of like dovetail really nicely to each other.

Carter Morgan (13:09)

You've done more consulting work and do more consulting work right now. But I also know that a lot of your work is more like with like startups. And so to me, it's like, I've been fortunate that most everywhere I've worked has had pretty good code. I've looked at code and been like, some of this is wrong. know, at my current place, like the code we inherited, like, yeah, there was just like,

Nathan Toups (13:12)

Mm-hmm. Yep.

Yep.

Carter Morgan (13:38)

a lot like, you know, like some 700 line functions, but my complaint wasn't with like.

the overall pattern of the code, like how it was modeled, like it actually made sense to me that like, okay, we, you know, have these controllers and these controllers called service methods and these service methods all farm their operations out to like database access objects, right? And like, it was all like the high level pattern made sense, but then just like the actual kind of in the weeds implementation just got very, everything was too tangled with each other. There was a lot of like,

this edge case is handled by one conditional 400 lines in here when maybe it would have been better to do like a kind of dependency injection thing, right? And say like, like, you know, there's a lot of like, if we're in development mode, then log this here instead of here. And I'm kind of like, well, maybe we should just have like, and like logs of ad is an example. Like a better example was like,

Nathan Toups (14:28)

Great.

Carter Morgan (14:42)

sending emails or something like that. And it's like, if we're in development mode, don't send the email instead, just log it. And I'm a little like, what if we have like an email sender class or something like that? And then at instantiation, you're inserting like whether it's the dev class or the, you know, the real class. Anyhow, but all that to say like, I haven't really worked at anywhere where it's just been like, this is a rat's nest. This is a big ball of mud, you know, a bunch of spaghetti. Have you ever seen that? Because

Nathan Toups (14:44)

Right.

Hmm

man, yeah.

Carter Morgan (15:10)

I feel

like that would make more sense because I feel that way about kind of a clean code by Bob Martin where it's a little like, I think people treat this a little too seriously or at least they used to, but this is an improvement over chaos. And so like, have you seen that just chaos?

Nathan Toups (15:24)

Yeah, so I've been really fortunate. of my, so I've got some good steady direct client work that I'm doing, but I also subcontract with a company that does managed, they provide managed Kubernetes and DevOps, really like mature DevOps best practices for pretty large organizations. Like I would say, know, organizations that are pretty mature and they've all been,

going through these sort of modernization efforts, and they realize they don't really wanna manage Kubernetes in-house. So one of the ways that they do is they have a of a paid discovery process. And it's been really cool to work with them because I basically get a glimpse at where really smart engineering teams have been struggling, basically like victims of their own success. And some of these are startups and some of these are companies that have established business models. And over and over and over again,

what you end up getting is the Chesterton's fence problem, where maybe there's been churn in the organization or there's been leadership changes that have happened and they know that things shouldn't be the way that they are and they know that they need to go a new direction, but they don't even know where to get started because there's kind of this ball of mud, right? There's just some fundamental thing that's just killing their velocity. They can't make some transition. They're kind of stuck with decisions from the past and it's tools like DDD.

that actually help you untangle, right? So this is where this inverse Conway maneuver and all the things that we've talked about, team topologies, is that you're like, OK, so I have this mess. I know it's a mess. I know I don't want to be here anymore. But I'm really afraid that if I make a change, I'm going to break the system and make it worse. And then I'm going to get fired, right? That's sort of the fear thinking that comes up. And it's reasonable fear, because you really can make things worse, right? You can kill the terminal patient, right?

Carter Morgan (16:54)

Hmm.

Yeah.

Nathan Toups (17:20)

And so how do I introduce changes or have a new way of talking to stakeholders? This is the other thing that I've noticed also in mergers and acquisitions. So I was at a series C funded company that we'd acquired a few companies and their product was good. But then you get it and look kind of look under the hood and you realize, man, there's some architectural and design decisions that were made with this that are incompatible with what we're doing. We have this nice, mature system, the gap between

their kind of mess and what we need to integrate is actually huge. It's this huge rift. And so again, it's another type of system in which we're forcing a system that's kind of working on its own into one that's actually a well-oiled machine. And looking at them next to each other, you realize that the first one's unacceptable, right? They will not be able to meet the pace of innovation and growth unless we get them to cross the gap and adopt these new patterns. And so these books, again,

are super interesting because I always look at how do we frame things and how do we reduce sort of like they call the blast radius of a mistake, right? Can I introduce a new way of thinking that actually gives us a flywheel effect? All of a sudden, the marketing team, they have these landing pages and they're super frustrated because anytime they need to make a change, it takes six months to make one silly little change. Could we change the way we communicate with them and set expectations so that

We're at least being honest with how long something takes, and then maybe we can even fix things sooner in the process so that we could iterate incomplete versions more quickly, right? Like all the things that we talk about doing like quick iteration. And again, it's hard to do that. Untangling something and then making it usable is way harder than starting fresh and having a clean slate.

Carter Morgan (18:59)

Right, right.

Yeah, it's a I also think there's a little bit with domain driven design where like it won and so there's some again is the whole like the fish doesn't know he's in water or you know the fish doesn't always what or whatever. Which is like, especially if you have worked at kind of more like Fang or or very much like the Silicon Valley style company right then like.

Nathan Toups (19:18)

Mm-hmm.

Carter Morgan (19:38)

It's very normal that you have like a user's team and a payments team and a shipping team and orders team. Whereas like we know it wasn't always like that. Like it was very much like, this is the database team. This is the whatever, you know, this is the backend Ruby team. and so, you know, like microservices really are very downstream.

of domain-driven design and this idea that you should model everything based on business domains. And it's probably worth mentioning kind of what those, some of the principles of domain-driven design.

Nathan Toups (20:19)

Yeah,

I actually made it if you look at it, I made a tab called DDD primer, which so in the idea here, and I think it is good to give context before we get into like the nuts and bolts of the book. The couple of the big ones to take away, and I think we've mentioned it a little bit, which is there's this sort of like tactical design and strategic design. I think we're going to get into that more that there's this concept that they call ubiquitous language.

Carter Morgan (20:24)

Okay, nice.

Yeah, yeah.

Nathan Toups (20:46)

I really like this. This again, this goes all the way back to the Evans book that started it all. But it's basically says, hey, if the business calls something, let's say an entity, they call it a claim, right? Let's say they're an insurance company. They call something a claim. The class recovering that thing better be called a claim, right? Don't invent new words that you're going to use the same language that the business uses, right? And that it's really our responsibility to make sure that we have to eliminate some.

translation layer that we really should be talking in the vocabulary of the business so that domain experts who we rely on can easily interact with us, right? Documentation should be in this. All of these things should serve that. It's a really important core principle. Model-driven design. Again, we've kind of hinted at this, but you're like, hey, we have to build a model of the universe. We have to understand how a business process functions, and we have to have a model to categorize this.

Whole point is that, if you try to do this globally, you're going to this huge mess. It's just way too hard. Too many people involved, too many stakeholders. And so you need to do thing called the bounded context. And this is something, actually, we talk about it, like the big client that I'm doing a bunch of work with right now, we're obsessed with bounded context. Like we talk about bounded contexts all the time. Do you ever use that term or talk about this much?

Carter Morgan (22:04)

Bounded context,

mean, we don't use it a ton, but when I was reading about it, I'm like, okay, this makes sense.

Nathan Toups (22:13)

Yeah, and so the bounded context, this idea is, and I think it's just what you were talking about here. A team owns a bounded context, and a team can even have multiple bounded contexts, like multiple applications that they're, services or whatever that they're dealing with. But one bounded context should not be owned by multiple teams. So I can have multiple services that I'm building, and if we don't think about bounded context, we just think like, yeah, these microservices or the user service and the auth service or whatever.

Carter Morgan (22:32)

Mm-hmm.

Nathan Toups (22:43)

One team could own both of those. That's fine. But what you don't want is like the QA team and the off team and the user team all kind of like owning aspects of the user service or something. That's where things get really messy and become a big ball of mud. And so, really, really clear that bounded context is a self-sufficient model into itself that it would...

Carter Morgan (23:00)

Right, right.

Nathan Toups (23:11)

you kind of are able to operate autonomously. You have to obviously understand the bigger system. about a context, she gave us a context map, right? This artifact that tells us who consumes what from where and who owns what and how the system. You really understand one little chunk of the system in its completeness with documentation and everything.

Carter Morgan (23:34)

Right, like if I'm

the user's service, I'm on the user service team and that's my bounded context. It's very likely that I'm going to need the orders for the user, right? But I am able to interact with those orders in a pure like consumer matter, right? And I don't need to know the nitty gritty of how those orders are processed, how payment is calculated, things like that.

It's kind of like if you can be abstracted away from the complexity of another segment of the business, then like, I think that's a decent test for what a bounded context is.

Nathan Toups (24:13)

Yep. And I'll tell you, I play a game all the time from the platform engineering and DevOps side. Bounded context should have, you should be able to take all of your bounded contexts and create a directed acyclic graph of its deployment pattern. So a good set of bounded context where you have nice abstractions is that I maybe, probably have a hierarchical structure, right? There probably is some, let's say we're talking about Terraform for a second. I might have a foundational Terraform deploy that really like bootstraps the system itself.

Carter Morgan (24:26)

Yeah, yeah.

Mm-hmm.

Nathan Toups (24:42)

But each of my services should operate independently. And if they don't, I need to have a directed acyclic graph that says, hey, service A, if it makes any changes downstream from it, service B and C have to know. And so therefore, I build this structure where what we don't want to say, if service A changes, then tell service B. And if service B changes, then tell service A. That's a problem. And ideally, amongst my bounded context, have no hierarchical structure.

Carter Morgan (25:06)

Right, right.

Nathan Toups (25:11)

for the services that hopefully those are embarrassingly parallel, that I've got this flat way of fanning out and doing these things. And again, when we start thinking about a bounded context, it doesn't have to be a service, right? One bounded context could be a shared library. One bounded context could be, you you can imagine these things in which a group is maintaining some chunk of reality, understands what the business needs. You these kinds of things fall into place. And now all of sudden you've a context for your

You have bound in context for your web applications. You have bound in context for all kinds of stuff that can come out of it. Again, this is why think things like DDD have really been helpful because it gave people a strong set of vocabulary to have these complex conversations.

Carter Morgan (26:00)

Well, and so I think that that's kind of like your primer on domain-driven design. What I really like when he's talking about this idea of bounded context, we're like, OK, so what does a bounded context map onto? And what it does, it maps onto a business domain. And he says there are three kinds of business domains. have core, supporting, and generic. Core.

Nathan Toups (26:06)

Yeah.

Carter Morgan (26:26)

this is your competitive advantage. You've got to build this in house. This is, you know, if you're at a tech company, this is, you what you're basically what's making you your money. Right. And so if you think about like Uber, for example, like some of their core domains are going to be like the actual routing algorithms that get like the, that match the drivers to the passengers, for Amazon, that's going to be their fulfillment net.

then you have supporting. These are necessary, but not differentiating. that, and this is, this made sense to me because I guess maybe talk about generic first, generic is like, these are solved problems, right? These are things like don't build your own cloud infrastructure. Just use Stripe for payments, right? these are totally fine to outsource. I, as far as supporting though, like I, I'm trying to think about like, what are, what are good?

domains that you think fall into supporting? maybe marketing? Is marketing a little like you might want to build some in-house tools to help facilitate marketing?

Nathan Toups (27:33)

You know, this is interesting.

I'm trying to think.

I think that this would be this actually I keep bringing up this idea of the the worldly the worldly map because there's this sort of maturity piece. think to me, again, roast us in the comments for screwing this up, because I hadn't spent a ton of time thinking about supporting. But I think that these are the kind of the the glue of putting things together. Right. Like maybe maybe we haven't fully gone to.

I think a perfect example of this, you know you need an observability layer and you haven't gone full generic, which is like, I'm going to go pick Grafana Cloud or one of these or Datadog or something, right? That's just sort of off the shelf generic. I'm not even worrying about it at all. But I might actually decide to self-host the open source version of Grafana, right? That is work that we're doing. We've decided to take this on, the reliability of it.

we've decided to take on the databases that support it, the ingest pipelines, all these other things. It's really not quarter of a business, but it's pretty important, right? Like architecturally, we're making a lot of decisions. And so it's not your competitive advantage, and it's not necessarily, it's not a differentiating factor, but it kind of helps with the way that things work. you end up having to, you you're talking about open telemetry and things like this.

you have to write custom code, right? Like you're doing custom things. It's not competitive advantage core. It's also maybe not even appropriate to go fully generic, right? Like you might need to actually do some custom stuff. And so I in a lot of ways that DevOps type pipelines, maybe self-hosting, internal, doing a mirror of your Python libraries or something. So you've decided that you want to take on the burden.

Carter Morgan (29:11)

Bye bye.

Nathan Toups (29:39)

of having your own package repository, something like this, it's not core. No customer is going to buy a widget from your factory because you self-list your Python libraries. And yet, you're probably not using some generic off-the-shelf thing. Maybe you're using JFrog or something, but you probably are running some sort custom-rolled stuff. These are the sort of supporting infrastructure that goes with that.

Carter Morgan (30:04)

Hey, this is only slightly related, but I've been curious about this. We read Mastering Open Telemetry by Steve Flanders. And in it, he's banging the drum repeatedly that you want to use the generic open source open telemetry and you don't want to lock yourself in with like the data dog SDK. Do you think that matters as much in an LLM world? Do you think you should just?

I mean, cause you could just kind of point Claude on Opus 4.7 and just be like, Hey, we're swapping from Datta dog to Sentry. Go change everything.

Nathan Toups (30:34)

Bye.

I am OK with it if there's certain patterns. And one of them, of course, is it's controversial depending on your style of things. But I'm a big fan of the inversion of control or dependency injection pattern. I'm OK with you pulling in Datadog SDK stuff if you wrap it in some sort of maybe logging or telemetry container that basically lets you hot swap. It does a couple of things. It nerfs.

Datadog a little bit, you're not gonna reach for specific Datadog SDK things in your business logic. But it does allow you to kind of like do this crawl walk run where maybe we do need some special magical Datadog runtime things, but it should really be encapsulated within your observability container, right? The observability sort of like dependency injection stuff. It also will make it a lot easier to swap things out. Cause again,

Datadog will not be forever, right? Datadog is not going to be a forever company. It may just stop being a company or it may just not be that great anymore or maybe it'll be great for the next 20 years. I don't really know, but I will say that if I'm architecting the system, I'm not gonna bet the farm on a third party vendor, right? Like that's not interesting to me. Actually, I was just doing a refactor this morning on my personal, I have a little website that I'm doing like experiments, it's called Funk.

Carter Morgan (31:53)

Right, right.

Nathan Toups (32:05)

and I built a couple little things on it. And I realized I was trying to write some end-to-end tests and it was kind of hard to mock blob storage because I'm using Vercell's blob storage. And I just made a little wrapper function that is, I just have a lib slash blob, which allows me to have an end-to-end test that uses like a self-hosted web endpoint that lets me sort of like do a fake of the blob storage. And what was nice about it is that it yanked a bunch of Vercell slash Bob

the blob dependencies out of my business logic. Like all of a sudden now, I have this internal library. I can now hot swap it between testing and production. It's a very small wrapper for the production workload. And again, it's exactly this, right? It's like, okay, well, now if I decide to get off for sell and use a different blob storage in the future, it's a much easier thing, right? There's like one little folder where I can hot swap the blob storage and anything else that was relying on that, just as long as it...

doesn't break the lib slash blob interface that I gave it, it's fine. And so, yeah, I mean, it's like a yes and, guess, is that yes, you should hopefully use the OpenTelemetry generic library, and you could use Datadog if it doesn't matter, if you have good inversion of control.

Carter Morgan (33:12)

Right, right.

Okay. Yeah. Now I can see that. I've just been thinking about that a lot because we are, uh, regular listeners of podcasts know about the ongoing migration of my company, which I'm pleased to say that we have achieved 93 % completion on with at least pages, the amount of pages on the website, like that talk to the old system, 93 % of them now talk to the new system. And then there's like some other stuff that we need to wrap up too. But anyhow, but just because it's such like a

bounded problem, like per page. It's just kind of like, I need you to replicate the old code in a new language with a new pattern. And I know that it works because I know that all the functionality of this page works. Like I have not been checking Claude super aggressively. And part of that is just a judgment call because I'm like, look, do I understand all of this code exactly? No. Did I understand all of the other code, you the old Java code exactly? Heck no.

Right? Like I understand this better. and you know, it's just, it's all trade-offs, right? Because it's like, we could move slower, but then we'd be moving slower. Right. And yeah, for, for any net new stuff I've been doing, I've been supervising Claude a lot better. And so, but just because Claude has been doing a very good job of like, like it doesn't really write code that doesn't compile anymore. Right. Like TypeScript. Yeah. Yeah. So we're using TypeScript, right. and so

Nathan Toups (34:47)

And you're using TypeScript, right?

Carter Morgan (34:55)

I do have a lot more trust in it with like, we've invested a lot of time and skills and we have good, uh, like agents dot MD files and things like that. Um, but anyhow, and so it was just kind of like, yeah, you know what? If, we were going, we were talking about switching to data dog right now, we just use like, uh, Grafana hosted by AWS and then Prometheus hosted by AWS. um, we're talking about getting data dog. And I was like, I don't know, should we just kind of.

point everything, just use the raw Datadog SDK. And then if you wanted to switch back, would it just be a couple days of work maybe? But I also think it just depends on what scale you're at. Yeah.

Nathan Toups (35:35)

I can tell you two things. Number one, it will not be a couple of days of work if you want to switch it back. And

I would highly recommend... So if we think about the open telemetry pattern of having a sync, so the whole idea is I might want Datadog strategically, maybe they offer great tools, but it really would... I've been in this environment before where we start with open source self-hosted.

we decide to pick a vendor. Of the vendors, Datadog does some really nice stuff. It's also very expensive. You'll find out that it's very expensive because they want you to log everything in there. And again, it may be that the expense is still good value and you want to use Datadog for that. But there's other vendors now that are huge. There's a company called CoreLogix. There's a company called, well, actually Grafana Labs themselves has phenomenal tools end to end. They even have, I don't know if you're already using PagerDuty or something.

but Grafana Labs actually has a, they actually have like a pager duty competitor and it's all in one interface, right? Like there's the whole world of how observability and on-call rotations and all these other things work has shifted so much. And some of the newer players do really cool things. Like again, I've had, I've gone from Datadog to CoreLogix. I've gone from Datadog to Grafana Labs.

I've even gone to self-hosted because at the scale, made more sense and we had enough team to go away. And I've never regretted abstracting away the observability platform. Because again, you just don't know it. It's cheap from an optionality standpoint. If we get back to some Ken Beck ideas, it's not some abstraction nightmare. You really are just saying, the logging

Carter Morgan (37:14)

Right, right.

Nathan Toups (37:29)

context goes into this thing and the observability stack, you just kind of put that in there and then the business logic just doesn't care. And we would even do this, it makes testing easier, which is that like you can default to the no-op logging library, right? No-op logging library. think Uber is the one who did this a while back where they created a framework so that you could spin up microservices, because they had like tens of thousands of microservices.

Carter Morgan (37:44)

Right, right.

Yeah, yeah.

Well, remember, we learned about that with Will Larson, right? Or wait, wait, no, no. Who was it?

Nathan Toups (37:57)

Yeah.

It might have been Jersey, actually. used to work. and think Stripe had a bunch of microservices, too. But when you do that, you basically end up having to have this orthogonal coupling pattern, where you have this idea that says, hey, I expect you to do all these things. All of them have been abstracted away at the service layer. So just write the standard out and do this thing.

Carter Morgan (38:02)

Jersey used to work for well, why are some work for stripe not?

Yeah, maybe that's what I'm thinking.

Nathan Toups (38:23)

be have a scrapable endpoint for your metrics or whatever, you just tell the teams to do that and they do it. And then if the DevOps team's like, Datadog, I don't want them anymore. I want to switch to Grafana. I don't have to have a conversation with 5,000 bounded contexts. It just.

Carter Morgan (38:39)

Right, yeah. Yeah, yeah. And

that's a fair point, which is like, as you get bigger and you're going to, I mean, it's very natural you might have a team that like, is your DevOps, this is your platform engineering team, right? And they're gonna be responsible for making all of those decisions. And so rather than being like, okay, everyone, rip out Datadog out of your services, you know, that's a good point.

Nathan Toups (39:02)

Right. Or there's a critical vulnerability

in the SDK and you have to go chase a bunch of people to get the thing in there, right? So that's the.

Carter Morgan (39:08)

Yeah.

No, that's a good point. I'm definitely thinking a little more like I've got startup brain these days. But it's I've just been thinking a lot about that idea of kind of like there's a lot of people who want to say like, everything about software engineering has changed. Like it's whole new world. You don't need this or that. like we talked about that with Mythical Man last week about like, OK, how much has changed?

I actually think there's a decent amount that's changed from the software development lifecycle. I think cycles have been compressed. I think there's not the need for just as much grunt work these days. And so that changes. In terms of how actual software is built and constructed, I don't think that's changed almost at all. Yeah.

Nathan Toups (39:56)

Yeah, mean, the abstractions,

and he kind of called it a lot in Mythical Man Month, right? He knew that the abstractions were gonna increase, right? People were complaining about compilers back in the day because they're like, if you don't understand the machine language, then you can't do anything. And he was like, that's not true. The other part, he was lamenting, course, in the book was, I really wish that there was a way to like have a piece of code that was sort of, could be reused by other people.

Carter Morgan (40:23)

Okay, yeah.

Nathan Toups (40:23)

And you're like, okay, well, the open source revolution hadn't happened

yet, right? We didn't have package managers, version control, the Linux operating system. None of that stuff had picked up by the time he even wrote the 20th anniversary edition, which completely changed how we write software. And I think that it's kind of interesting too, because these patterns, we get spoiled on all the great things that we just take for granted.

You know, if you actually look at like, how does a build solver work? Right. It is doing some really cool computer science things under the hood with like understanding cache invalidation and hashing and integrity checks and all these things that like if you actually wrapped your head around it, you'd be amazed, amazed that we're doing things with the level of certainty that we have. And yet, you know, people are also yoloing unproven skills and like compromising databases and, you know, getting exploited all the time.

because we haven't wrapped our head around when a cool system is used in a way that's not intended to be used.

Carter Morgan (41:30)

Right. All right. Last tangent. But I had this thought the other day. Do you think that Anthropic or OpenAI are trying to develop their own programming languages right now that are like super token efficient and optimized for the models? Just because like, I've just been thinking a lot about their business model and like, obviously they're doing very well for themselves. There's no doubt about it. But like Opus 4.7 is already very, very good. And honestly, if Opus 4.7 never improved, it'd still be a very, very valuable product. Right. And isn't it

Nathan Toups (41:39)

Hmm.

Carter Morgan (42:00)

It's not crazy to imagine that in two or three years, an open-sourced model will become as good as Opus 4.7. And so if I can get in three years from now, the performance of Opus 4.7 for free, basically, why, exactly, right? Like why go with Anthropic? And so I know they're just thinking constantly like how to get vendor lock-in. like, I don't even know this would work, but I'm like,

Nathan Toups (42:16)

Running on a Mac mini at your house, right?

Carter Morgan (42:29)

I wonder if they would try to invent like a proprietary programming language that's like super token efficient and is like trained to the max on their models if such a thing is even possible. Cause obviously you have a huge disadvantage compared to like all the training data for everything in the world. but I mean, talk about vendor lock it, right? If you just say like you built it in our proprietary language.

Nathan Toups (42:49)

Yeah,

I didn't bookmark it, but I did read in passing something on Hacker News where a group was claiming that they're working on a large language model friendly programming language. I didn't really take too much of notice, but I do think that that domain of thinking is going to be interesting. Actually, I think it was braintrust.dev who does, they do telemetry in eval stuff.

Carter Morgan (43:03)

think I saw that, yeah.

Nathan Toups (43:18)

Eval work on top of large language models. They're a really cool company. Full disclosure, I used to work under that CEO at previous company he worked in called Empyra that was acquired by Figma. But he brought up something really interesting, which is that they did a bunch of internal work that large language models do incredibly well with SQL. And that if you actually can translate a question as a SQL query,

Carter Morgan (43:27)

Nice.

Hmm.

Nathan Toups (43:46)

that it actually does a much better job than like for certain types of, and again, there's like some caveats, certain types of questions that you ask the large language model, it can express itself more accurately using SQL than even a bunch of other programming languages. Cause they were curious about this kind of question. And I think some of it has to do with like tuple calculus and some of the other like underlying principles that they go into this.

Carter Morgan (44:02)

Interesting.

Nathan Toups (44:11)

I think it's also because it requires you to structure data in a way that is SQL expressible, right? So I do think that there are some constraints there. But it is interesting to this idea, this inversion of saying, is there a way that we can structure data and structure code and structure things so that it's easier for a prompt to come back with a useful reply, right? Can we do this in a way that we can maximize the odds of our success?

with our intended desires. I don't, it seems like such an obviously true way of thinking about stuff. It's the same way of like, a perfect example, my mom would tell us this story where she was just like, it was raining and she wanted me to wear my raincoat. And she did not want me to get, to be obstinate, because I was a very obstinate kid. And so she would say, Nathan, would you like to wear your red raincoat or your blue raincoat?

Carter Morgan (44:46)

Right.

Nathan Toups (45:09)

and I would say the red raincoat. And she's like, cool. And I never thought of there's no option for not wearing a raincoat. And is it manipulative? Yes. But did she get the outcome that she wanted? Also, yes. She didn't care which color raincoat I picked. She just wanted me to pick a raincoat. And we did not get an argument. went to school and I wore the raincoat like she wanted me to. I think that we have to do the same thing with our language models.

Carter Morgan (45:14)

Hahaha

Right, right.

Well, okay. Thank you listeners for indulging me in some of these tangents. I want to get back to some of this stuff with subdomains. One of the really important principles Vlad mentions here is that subdomains are discovered, not invented because yeah, subdomains, you're modeling the real world. he has, I don't remember, this is not his quote, it's a quote from someone else, right? I don't remember who said it. says, all models are wrong, some are useful. And I really love the example he gave with that, a map.

Nathan Toups (45:53)

I loved that. Yeah.

Carter Morgan (46:08)

He said, it's like maps are models, right? And like a map is not going to be, by its nature, it is not a 100 % faithful reproduction of the world, right? But there's lots of different kinds of maps, know, like maps meant for driving, maps meant for hiking, you know, topographical maps. And depending on what context you're in, that's the map you're gonna reach for. And so I'm a big fan of modeling things and I think it's very...

I think there is a type of engineer who gets really frustrated at an inability to express all of the edge cases and all of the details surrounding a problem in a model. But models are very, very useful because they provide a shared language for all the members of a team, including the non-technical members, to discuss a problem. I know that's a...

and made to stick. Chip and Dan Heath talked about this idea of like, sticky ideas are concrete. And one reason that something being concrete is really helpful is because everyone knows what you're talking about, right? Like there's no room for interpretation. It talks about someone who was giving a pitch, I think for the Palm Pilot, or it was like some sort of tablet or something and like, the pitch was going well. And so eventually just kind of like throws his like folder onto the table.

and says like, know, gentlemen, imagine, you know, like it's like his binder, like, imagine a device that could do this, this and this that fits in your hand like this. But then the moment people kind of started picking up the folder and going like, oh yeah, you know what, like it kind of made the idea real. And they were like, could you fit it in this? You know, what trade-offs would you have to make? I think it was the Palm pilot who like, he carried a brick, just like a, or like a wooden block in his pocket. And anytime anyone would like propose a feature,

Be like, can it fit in this? Like, this is what we have to work with here. And so, I think models are good because they, they force you to understand the problem you're working with. I think in creating a model, even if it's a simpler model, they might like it to be that forces you to understand the kind of trade-offs you're dealing with. And I think it's something to say, like, if you think that a topic is too insignificant to kind of fit into the

Nathan Toups (48:06)

Right.

Carter Morgan (48:34)

model for the problem you're discussing, that's a worthwhile signal into how much time you should be investing in building out that part of the system.

Nathan Toups (48:44)

Yeah, I did, again, I love that bounded context are designed, subdomains are discovered, right? And that he also argues in here that while many times a bound on context in a subdomain can be one-to-one, they're not necessarily one-to-one, and that a subdomain can actually span multiple contexts, right? So again, it's a framework for us to think about how do we divvy up responsibility and work in these other pieces. I also loved that

The, what was it? Let me see, boundaries are, the boundaries are physical, meaning that there's, oh, actually, here's what it was, inside of a bounded context, the ubiquitous language is consistent. And across context, the same word can mean different things. I actually ran into this recently. So I think this will be good one to bring up. I'm working with a company that does,

Carter Morgan (49:36)

Right, right.

Nathan Toups (49:43)

loan underwriting for construction loans that transition into building projects. And it's funny because when you go and close on a house, so we call it closing on a house, and it's funny because you could close on a house where both the buyer and the seller have no mortgage involved. I could have a house and you could want to buy it from me, and we'd just do a

cash deal. We still call it closing. We close on the house. It's like all the paperwork that gets done and things that go on. And then we also have the loan that's actually issued. And the way they think of closing is the loan closes. So the loan closes at the end of whatever the term is. Like you've paid all of the 15 years on some loan, or maybe it's a construction loan, so it's only a couple of years long. Or maybe you go into foreclosure. There's all these reasons that a loan would close down the road.

That's a very different term for closing than closing on a real estate deal. And yet, they will overlap. So I could close on a house that closes out my mortgage because you've paid money, you started a new mortgage, the check that's written pays the balance of my mortgage, and then the rest of that cash goes into my pocket. It becomes really confusing. And this was like an argument that was happening internally.

Carter Morgan (50:48)

Right, right.

Nathan Toups (51:10)

I'm like, who owns the term closing and where's the bounded context for like, we have to understand that closing means something in this part of the business and this part of the business. so it was like this, it was a perfect example. We didn't have to have a universal understanding of the term closing. We had to have an understanding of the term closing amongst its bounded context, right? If I'm talking about the loan life cycle, it has a specific meaning for closing. If I'm talking about a real estate deal, it has a specific, you know,

Carter Morgan (51:32)

Mm-hmm.

Nathan Toups (51:40)

reason for closing. yeah, that's just a concrete example that came up recently.

Carter Morgan (51:45)

Well, I want to talk. We've only got a few minutes left before we end the episode. We've talked about some of the code examples in this book. And again, it's just a very kind of like consultant, enterprisey way of writing code. We do a lot of functional programming at my work. so it's just not my.

Nathan Toups (51:53)

Hmm.

Carter Morgan (52:10)

my style of things. don't know, Nathan, if you want to pull up some on your end, I mean, I can pull up some on my end. mean, a lot of these things like are not crazy to me, right? Like you have a person class and that person class accepts an ID and a first name and a last name and a landline phone. Like it makes a lot of sense to me. You get to some things a little where it's like, the idea of domain driven design, right? Is that you can model these, you can model everything in code.

Nathan Toups (52:25)

Yeah.

Carter Morgan (52:38)

all your code kind of maps to real world representations of the stuff you're working with, right? And so yeah, you know, uh, value objects, is there identities by value immutable? They encapsulate data or behavior. Some example, like money, color, address, you have entities that stuff like customers and orders. I don't know. I get a little bit like you have here, like var phone equals phone number dot parse. And then it's, and then it's a string of a phone number. I'm a little like,

Okay, I see some value in that. see some value in like, let's isolate all the phone number parsing logic to a phone number class. And so I can be assured that when the phone number then gets attached to the customer object, it's a valid phone number. I get it. Part of me also feels like phone numbers are strings, right? And like, I'd rather just do some validation on the string.

before attaching the string phone number to a person, you know?

Nathan Toups (53:36)

All

Yeah. And again, these are two different schools of thought, right? Do I have this phone number object that lets me manipulate all these things? And I could ask it questions of like, give me the area code or, you could imagine if you're dealing with phone numbers a lot and you really care about country code versus this versus that. Yes. But a lot of times I think also the functional programming or, just having function first stuff where, you know, you have a phone number validator that takes in a string.

Carter Morgan (53:53)

Right.

Nathan Toups (54:09)

and then lets you know if, basically like protects whether this phone number is properly formatted and deals with some stuff in a very flat functional way. Do I actually need a phone number class or phone number object to describe this? I think it really comes down to what's needed. For instance, if we're dealing with things like a URL,

I actually think that a URL is really nice to have a class for that, or some sort of structure where I'm like, OK, give me URL.parameters, or give me URL.theQuery, is this thing in the URL? Or having it sort of this sort of object-oriented could be really nice. But if you want to keep things simple, you're just like, URL, is URL valid? And then you pass in the string, and then it just tells you yes or no. Those things.

Carter Morgan (54:42)

Right, right.

Nathan Toups (55:08)

They're fine too. guess I, it really comes down to, to me, it comes down to like.

I think this would actually come down to some of the ubiquitous vocabulary conversations that you would have too, right? Is one of your claims to fame, is one of your core competitive advantages that you handle phone numbers better than all competitors. And you really do, you can validate the accuracy and usefulness of a phone number 17 different ways, right?

Carter Morgan (55:35)

Right.

Nathan Toups (55:46)

then yeah, you probably do have an object in bajillion ways that you can actually slice and dice those things. the examples in this thing definitely feels very enterprise-grade code. And I think everyone knows if you've seen that, right? It's the Java and C Sharp type coding styles where you're like, wow, that's a lot of boilerplate to do something that seems somewhat simple.

Carter Morgan (56:11)

Yeah, yeah. Like, and I remember that XKCD comic, is like him saying like, if you wrote an essay in every language, and the joke for Java is like, you're six pages in, and I still know what you're saying yet. And I remember reading that in college and Java was the only programming language I had ever worked with. And I was like, what do you mean? Like, it's how could you be any shorter than this? And then like, you start working with something like a Python, you're like, wow.

Nathan Toups (56:35)

Yeah.

Carter Morgan (56:40)

Were there any other code examples you wanted to talk about Nathan?

kind of, you know, you get the gist of it.

Nathan Toups (56:47)

No, it's just,

again, I wouldn't, you you're not gonna, you're not coming to this book for the code. Again, I'm not a C sharp programmer. It was very easy to understand. I think maybe because we're, a lot of us are writing TypeScript and the same creator of C sharp and TypeScript is the same person. You know, there's a lot of, there's a lot of overlap and similarities, but it doesn't bring me joy. I do kind of wish maybe that this was in Python.

Carter Morgan (56:55)

Right.

Nathan Toups (57:16)

which I think is an easier sort of casual language to read. But I also, just because I'm like, yeah, forget about how languages are obsessed with getters and setters and all this other stuff. again, from an enterprise standpoint, not surprising. And I will say, I was reading a lot of this book sort of adversarially being like, what would Osterhout think about these things? And I will say that I think in the realm of strategic DDD,

there's actually a lot of good overlap with philosophy of software design.

Where I think that this book kind of gets hung up is that, and I think this is just consulting industry in general, the last responsible moment, the idea of pushing things off to last responsible moment or having sort of these tactical phases, I do think really if you have that tactical tornado type person in your organization, they really could go completely buck wild with tactical DDD.

where you end up following DDD, but you're in such a tactical tornado that you've basically pushed off elegant, deeper strategic thinking for technically implementing what was asked, right? And I think DDD could be exploited that direction pretty easily.

Carter Morgan (58:16)

prime.

Well, why don't we talk about, give us some of our hot takes here. I don't know, I wrote like, maybe my code is terrible. It's possible my code is terrible. I don't think it's terrible, but like.

The whole idea of bounded context and modeling the real world, this kind of comes very naturally to me. It has never occurred to me that you could write code in another way. I don't know if everyone thinks that way, but it's just very clear to me. Of course, your code just maps onto what you're trying to model in the real world. In fact, it seems way harder to me to code in any other way.

I don't know, tell me, am I crazy here, folks? I don't know.

Nathan Toups (59:23)

I think there's two sides to this. Number one, if you walked into an environment in which they have a nice, well-reasoned set of principles that they build things with, which I think you've had the advantage of having, you're correct and you get a sense of aesthetics, right? There's a sense of aesthetics that you understand. You're like, this is what good feels like, right? I do think though, you know, it would be interesting to revisit this in like two years. If you're at Leland,

Carter Morgan (59:34)

right room.

Nathan Toups (59:52)

and you're like, how do you feel about the decisions you made or your understanding of the business? Because the other thing that will happen is the business changes, right? And so all of a sudden, what a stakeholder or what the requirements or how the bounded context makes sense shifts because the business itself, you know, they have a reorg or they think about something new and all of a sudden your bounded context in the sub domains are not mapped up properly anymore. And I think that's the other part is just like,

Carter Morgan (59:57)

Right. Right.

Nathan Toups (1:00:23)

And I've noticed this in some of these mergers and acquisitions, or these other things, like somebody did a rug pull, or somebody made some change to their understanding of reality and the model no longer fits. And so how do you react to that, which is a hard thing to do? So yeah, I think that's the other side of it. Is that even if you did a good job today, is it a good job because of the external realities in a year?

Carter Morgan (1:00:44)

Right.

Yeah,

no, that's fair. And I am looking for it. I intend to be at Leland for a while. And it's also nice at Leland because I've been leading a lot more decisions that like, I know Gerge has talked about this, like, it's tough if you have a developer who hasn't stayed somewhere too long because like what you need, you need to reckon with the consequences of your decisions, right? And I hope to reckon with my decisions. I've already reckoned with some of them.

Nathan Toups (1:01:06)

Yep.

Yeah,

and some of the best learning you'll ever have is that, you know, I've definitely regretted doing some of the job hopping that I did during the pandemic, because I did some of my best work, at least what I thought was my best work, and I didn't get to live with it two years later to see if that actually was a good idea. You know.

Carter Morgan (1:01:29)

Right,

Yeah, but you know, they paid so much during the pandemic. That's the problem, right? I kind of look and I'm like, should I have left this place for that place? I'm like, well, the next place was offering you a 50 % raise. like, yeah.

Nathan Toups (1:01:42)

Yeah, I did the same thing. It was

for my family, my bottom line for me playing catch up on my retirement accounts and things like this. Yes, I'm no regrets. No regrets.

Carter Morgan (1:01:49)

Right, You

and Nathan. Any hot takes?

Nathan Toups (1:01:54)

Yeah, so I kind of mentioned it a little bit. Yeah, I didn't push it too much, but yes, this book is very, like, I guess C Sharp is super class heavy, but it felt like a very classitis or Osterhaut argument there, which is, you know, there's a class of a class pulling in a class. Like, there's a lot of very deep, or I should say shallow classes that are being pulled in a lot. But again, that might just be a coding style that's different.

what I'm used to. The other hot take I had was that, and again, I kind of mentioned this earlier a little bit, is strategic DDD is very impressive. Tactical DDD feels like it could be a complete mess. And I think that if you skip straight into the sort of like tactical modification aspects of DDD, you could even probably give DDD a bad reputation if you're not careful.

Carter Morgan (1:02:38)

Yeah.

Yeah, I think you're right. And I've been thinking about this a lot at work, which is like, there's some developers that love, know, like that kind of very tactical nature. And I think it relates to kind of like Will Larsen's like snacking, right? Where it's like, you just want to go in and you just want to fix this thing and, you know, polish that up and whatnot. And it's a little like, I think that's useful. I think.

Nathan Toups (1:03:03)

Yes, yeah.

Carter Morgan (1:03:14)

It doesn't replace, doing a lot of that does not replace driving key initiatives. We're seeing that with some engineers, where it's like, no one is unproductive, but you need to be kind of, I don't know, you need to be driving things in a more significant way. And for what it's worth, think that's true with AI, which is like this like.

Nathan Toups (1:03:36)

Great.

Carter Morgan (1:03:42)

just here a little there a little, you know, just doing a little bit of this, a little bit of that. Like, I don't know, I think the time has come for us to be owning larger initiatives from end to end and really moving the needle in a significant way. I mean, that's why I really liked slow productivity when we read it almost like a year and a half ago at this point. Just that whole idea of like pseudo productivity and like, you know, you can do stuff that feels like work, but does it actually move the needle? And ever since then, I've been like, got to

be focusing on stuff that moves the Minorly related to this idea of strategic versus tactical domain-driven design. But I do agree that if you just start modifying the code without a bigger picture, are you really going to make it better? Or are you just going to introduce weird pockets of domain-driven design that just make the whole code base more complicated to reason about? As far as what we're going to do differently, because we've read this book,

I would like to model our subdomains. We are a small enough team, a small enough business right now that we have, like, we only have one engineering team, but like, you know, the hope is raise a series B in the somewhat near future. And if that happens, I mean, I think it's very possible we grow from 10 engineers, I think we're at 12 engineers right now actually, to 30. And I think it would be reasonable at that point to try to split it up and say like, okay,

Nathan Toups (1:04:41)

Hmm.

Carter Morgan (1:05:06)

these engineers focus on this and these engineers focus on this. And even if that's still at that point, like a model repo and it doesn't make sense to go like a full microservice approach, I still think it makes sense to have domains. And I've just been thinking about that lately. What would be our domains? What would we split off? And I think I should just get ahead of the curve on that a bit. How about you?

Nathan Toups (1:05:27)

that's cool.

Yeah, I'm going to double down my efforts on the ubiquitous language. We already started doing this. We've been in the process of like, we've been using a lot of external schema and other data stuff in this big data warehouse I'm working on. And we're working on what we're calling like a unified schema, this idea of only including stuff that makes sense internally. And all of this has been led by our stakeholders, you know, the domain experts that we've been working with directly.

And I've learned a lot about the vocabulary, but I don't think I realized how important it was that I absolutely always use the vocabulary that they use, right? That I'm the one who is modeling their world into what we can do in deterministic, repeatable processes. And yeah, I'm going to put extra effort into that.

Carter Morgan (1:06:18)

as far as we're going to, or who'd recommend this book to, I'd say if you're an engineer who kind of struggles to understand the business and just find yourself really absorbed in the code, this is a good book to kind of get you started. and yeah, I I'm banging, I've been banging this drum for a long time. Both of us have, but like this idea that you can just live purely in that, in the code, in that accidental complexity world.

Nathan Toups (1:06:27)

Hmm.

Carter Morgan (1:06:45)

It's never been a good career decision. It's certainly not a good career path and it's possibly not even a career path at this point. you know, if you want to understand like, okay, how does the business map onto the code? this is a good book to start with.

Nathan Toups (1:06:51)

Great.

Yeah, I completely agree. I'd say this book is really super important too for senior engineer and engineering leadership that maybe is struggling to figure out how to get alignment in a more mature organization. So again, you've maybe been in environments where things just worked, you kind of took it for granted and you're walking into a lot of dysfunction or you're realizing that domain experts don't know how to even communicate.

This gives you lot of tools on how to deal with that. But I love your framing. think actually, it's a really good point. Maybe that's the other big takeaway is we all have to think about the business. And so if you don't really like the business you're working in, you should probably find another type of business. If you really do want to get to low level stuff, maybe your customer should be other software engineers who look for kernel exploits. And so you work for a kernel exploit software company, right? And then you can get in the weeds all day long.

Carter Morgan (1:07:51)

Yeah, yeah, that's a point.

I used to think with myself like, I don't really care what I'm working on so long as the tech is interesting. And I realized like, that's not true. I have to care. I have to be interested in what I'm building. Yeah.

Nathan Toups (1:08:03)

Yeah, I'm in the same boat. I used to say, I was like, as long as I'm solving interesting problems. And I just,

that's such a cope. It really is like you, you actually have to get excited about the product and who you're working with or the bad days are going to be so bad. Right. yeah. Hmm.

Carter Morgan (1:08:18)

Yep. And that can be a lot of domains. Like I did not fantasize

about building a one-on-one coaching marketplace, but I do find marketplaces inherently interesting. And that makes my job a lot more interesting. Well, anyhow, folks, we got to sign off, but thanks for listening. We'll be back with part two next week. Find us on Twitter at BookOverflowPod, email us at BookOverflow.io. I am on Twitter at Carter Morgan, and Nathan has worked with his consulting agency as at functionallyimperative.com. We'll see you later, folks.

Nathan Toups (1:08:26)

Yep.