CoRecursive: Coding Stories - Tech Talk: Domain Driven Design And Microservices

Episode Date: August 17, 2018

Tech Talks are in-depth technical discussions. Today I talk to Vaughn Vernon about how Domain Driven Design can help with designing microservices.  The guidelines that Vaughn has developed in his work on DDD can provide guidance for where service and consistency boundaries should be drawn.  We also talk about the platform he is developing for applying these DDD concepts using the actor model, Vlingo. Show Notes: Implementing DDD Book Vlingo Platform Vlingo Source  

Welcome to Code Recursive, where we bring you discussions with thought leaders in the world of software development. I am Adam, your host. Ask a domain expert, when do these two pieces of data need to be consistent. And if you ask enough questions around when you show them that immediately is not such a great idea in this particular case, you might find that seconds or minutes or even hours of tolerance between consistency is actually possible. So, that's where the complexity of and the diligence comes in with trying to model these concepts because figuring out those boundaries sometimes can be a challenge. If you are a talented Scala developer or a talented developer in general, my group at Tenable is hiring. We are looking for a principal software engineer for our web app scanning product. Tenable is a great place to work.

This is a distributed team, so you could work from your home office or at one of Tenable's many office locations. I will put a link in the show notes to the job, or you could email me at adam at corecursive.com. Today's guest is Von Vernon. He is most well known for his books on domain-driven design. Today we talk about how domain-driven design is a great tool for finding service and consistency boundaries.

Enjoy. Yvonne, welcome to the podcast. Thank you. Thanks for inviting me. So I was... Funny story about how I decided to invite you to come on here. I was on my treadmill doing some walking and I have my laptop mounted up on there. I'm watching some YouTube tech talks and trying to get up to speed on microservice architectures. And I saw this video you gave.

It's a couple years old I think in fact but you were talking about domain-driven design and how it related to microservices and I had never really heard these two terms used together and like at one point domain-driven design it was something I was pretty excited about and I kind of forgot about it. And then here you are bringing these concepts back to mind for me. Kind of exciting. So what does domain-driven design have to teach us about building a microservice? Well, I just have to say, probably as you've kind of alluded to here, microservices has a very sort of loose and not well-defined

meaning among the software development community. So in an effort to try to put some real meaning around it, my efforts have been to talk about the fact that DDD-bounded contexts are relatively small in size and that this is a good starting place for microservices. And if you've read Sam Newman's book on building microservices, he starts from the perspective of a microservices and DDD-bounded context. And he directs you to Eric Evans' seminal work on DDD, but also references my Redbook as a, I don't remember exactly his words, but something like a practical example of how microservices can actually be implemented with domain-driven design. So it aligned with my ideas on it,

although there are still various definitions of what a microservice is. So I can go into more detail on that if you want to, but I don't want to ramble too much. So what is a bounded context, and why does it make it a good place to draw these lines between services? A bounded context is an area of a system where a specific domain model has specific meaning.

So one way to describe that is around the language or linguistic drivers. And DDD promotes what is called a ubiquitous language and a ubiquitous language is developed within a context boundary. So any modeling elements that you have inside that boundary have a very specific meaning. And one good way to describe that is to talk about the word product. What is a product? And even if you work in an area of a business where you think that product is well-defined, you'll probably have to admit that product, in reality, has several different meanings.

Even if they're referring to the exact same digital item or physical item, say it's a watch that we want to wear on our wrist or software that we want to download, that product has a meaning in a product catalog. It has a different meaning in an inventory system. It has a different meaning in a shopping cart. It has a different meaning in an order management system. And even though all those subsystems of a whole system are related to each other, as that singular product is dealt with in different situations, those are different contexts. product catalog context have different definitions for describing that very same item as in a watch that you want to wear on your wrist. One is concerned with price. One is more concerned with just do we have it on the shelf, right? It doesn't necessarily really matter what the price is or what discounts were offered in purchasing it. We just need to take it off of a shelf and ship it. So as you move

around that whole system that's working together, the word product changes. And DVD gives those contextual differences a boundary to live within. And so in those four or five different situations that I described, there would be four or five different contextual boundaries or a bounded context. In the inventory system, in the inventory bounded context, which we're saying could be its own microservice, it would just know about counts? It wouldn't know about pricing? Is that the idea? Well, it might have some sort of to color, or it may be. It could be that the identification number on it is about color, but it may have a description as to color and a general description such as Apple Watch or something like that. So you can see and say, okay, this is an Apple Watch.

This is a black Apple Watch or a silver Apple Watch, and this is the one that I need to pick. And sometimes the SKU number has that identification, the full identification. Sometimes it doesn't so you may have a skew and and you may have additional description but we're not really worried about the skew so much in a product catalog we know we probably know what each of the skews are but we don't necessarily present that to the user because they may not be interested in it. Or it could be that the SKU itself doesn't even reach the product catalog. It's a completely different unique ID, but has

some sort of a basically foreign key relationship to some other completely disconnected part of the system that allows you to look up the SKU for that. It really depends on how the system is modeled. Right. Why is that a powerful way to split these things? Yeah, because if you don't split them, think of the alternative is put them all together. So we have one canonical model element that lives in one place in the whole system, and it tries to define everything about a product that everyone will possibly want and sometimes those different properties of the same item can work in conflict with each other right it's and but even if they don't work in conflict or aren't completely

misleading or whatever in in many cases, they're irrelevant. And so you end up creating, you know, a model that sort of fits the, or that goes by the description of one size fits none, right? Or one size fits one or maybe a few, but the other 10, not so much. And, and so, you know, this way you have a very specific, very explicit way of looking at a particular model concept in a specific context. And it has a very definite meaning and, you know, and it works just for that one area. Being explicit is so important because when I say the word product, what does that actually mean? If I say the word account, what does that mean to you? Probably your mind first draws the conclusion that I'm talking about a bank account, and that, right, or something. And, and so you, you've already concluded that

I've described, you know, I'm talking about a bank account, but way over on the other side of the universe of that definition, what if I'm talking about a literary account? And that, you know, that really throws you for a loop, because probably most people would never think or they would have to search their mind for quite a bit before they would ever think of the word account being used in a bookstore or a library or something like that, like Shackleton's Adventures to Antarctica, a concept like that. So yeah, I think it's quite important. But when I name the context as in literary context, and I say the word account in a literary context, I've got a pretty good idea of what I'm talking about. Whereas in another context, such as, you know, if we're in a library

and it's simply someone, you know, a library, someone who, you know, I forget what it is, I guess an account holder at the library these days has a library card or something that they use to check out a book. What is that literary account according to that individual's library account? It's just a book, right? It has a title. It has, what is it, Dewey Decimal or something to identify the book. But it's just a book on that account. And yet when I go look it up and some particular context, it's going to say, well, it's in the, it's in the literary account section of the library, you know, or the, the, um, uh, adventures section or something like that. By, by cutting, by being specific in the context, these, these things have a lot more

meaning. So in our, in our inventory system, we, we only need to know about this, you know, keeping track of the books and then at the point of sale or whatever, then, you know, an account is a whole different thing. So how, how, how do these systems communicate with each other though? I mean, the point of sale system needs to know about the inventory for instance yeah well i mean that depends um if you're talking about maybe the new york city library system or the tokyo you know what i'm just giving examples of the potential for a huge library inventory and and operations going on, it's probably a distributed system.

But if you go to the Burt Mattress Idaho library system, it might be an old D-base system working on a single FoxPro or whatever, working in an isolated workstation or a few workstations against a server or something like that. But the point is, you know, it depends on the scalability needs and the number of users that it has to surface. It could be that it's written as what we might refer to these days as a monolith, where the whole library system resides in a single sort of executable that gets deployed or whatever, run in a single server or something like that. And that's the pretty simplistic viewpoint.

But in a very large system, you can imagine someone who decides, well, we're going to write the library operation software to beat all and every library in the whole world is going to use our cloud-based SAS library system. Well, I mean, there's a lot of replication and distribution going on in that situation. And so you would be using probably messaging to communicate occurrences from one context to another, whereas in the smaller system, you might just be talking in a loosely coupled,

maybe even multi-threaded situation, but even not necessarily so, but just in a way that's loosely coupled to keep the components across contexts separated from each other. But still, it could function in the same thread in a decoupled way. So you kind of have those extremes. So loosely coupled how? Through well-defined interfaces.

You know, look up a service you could think of it as like a directory service or service directory or whatever you want to call it like you know in the same fashion as web services or something like that and you just have a name and say, give me this, you know, this service. Now you have an interface, but you know nothing about the actual implementation. And you invoke some methods on the interface and you get something back. And to you, as a developer,

you, you know, you sort of don't really need to understand, is this just a direct method invocation on, you know, in my same VM? Or is this traveling over just a direct method invocation on you know in my same vm or is this traveling over a network or is it you know i get it so it sounds like that to you the you know the bounded context is very important and then like whether those actually become standalone things is more a concern of scaling. They should always be loosely coupled, but then they should be the actual whether they're deployed as separate actual services is an issue of how big things are. Yeah, I mean, how far they have to scale, how broadly it's used. I mean,

potentially, I guess you could deploy this sort of very small monolith into AWS and, wow, we have a cloud-based system. But in reality, if it runs against one MySQL database or something and it's all just in one small container, I mean, maybe that has some benefits, but that's not really the way the cloud is meant to be used, right? So if you naturally think if you're deploying to AWS, well, you've probably got containers, you know, well, potentially all over the place, even around the globe, but probably at least in different data centers, different regions. And so they're talking to each other in that way too. But they do so through messaging or sometimes through REST or SOAP or something like that.

It's not like, you know, DDD doesn't actually tell you which of those mechanisms you should use. But in some cases, like if you're using domain events, those sort of naturally fit into a messaging environment. But on the other hand, you can always deliver messages through atom logs, right, of groups of events that have occurred, and you can consume them through hyperlinks and say, okay, give me the current log, and then have I seen this log yet? And if not, we can actually navigate back through previous logs until we find the event that we've already consumed and then consume everything that's available from...

So what's the Atom log? Is that what you said? Yeah, well, like the Atom feeds on the web. If I have a blog, right, and people want to subscribe to my blog, they can read an Atom feed. Yeah, so we can design domain event logs in much the same way. And so how do you get all the blogs for the past year that someone has written? Well, if they, if they blog regularly, you know,

once or twice a week, that may be five different feeds, or maybe it's a feed per month or a feed per week, you know, so that could be 52 feeds, let's say. And so to get a handle to each one of those blog posts, you have to read all 52 of those, but you can navigate them through Hyperlinks. Yeah, that makes sense. It sounds a little bit like hand-rolled Kafka. You're just keeping track of where you are in this blog file, right? Or in AtomList.

Yeah, my guess is that kafka was born out of those concepts i wonder actually what you know um i think my book was one of the first to um present that idea i i wonder if you know was my book an influence on how kafka was implemented i know it's had a big influence in other areas just that concept right and definitely like i know i tried like years ago i was working on team we tried to build like a kind of event sourcing system this there was no kafka at the time i mean i guess we did i think think we serialized objects to a table. It was actually super complicated.

But I think these concepts have been around for a long time. It's funny you mentioned D-base. So my first job when I finished university had to help maintain a D-base system while rebuilding a better replacement. But I think that, like, domain-driven design, it tends to focus on, to my understanding, like, business requirements. And there's no, like, business requirement

that says that you need to have this running in a container on AWS. Like, I mean, D-base was ugly, but for all its problems, you could whip up something pretty quickly, right? Yeah, and I, you know, I was just, again, naming some extremes, but I actually, in a business back in the 80s

that I started, a software product house, we used Rbase instead of Dbase. I think Rbase disappeared before Dbase did. I think it showed up after and disappeared before. But yeah, similar ideas, and then I think FoxPro was pretty similar to that, at least

the earlier versions. But DDD is... I think the best way to describe DDD is you've got a really hard problem to solve. And you want to make certain that you solve it with explicit concepts. And you also want to isolate it from the rest of the system that may not be so well defined, right? So explicitly defined. And so to some extent, maybe you could actually even use a D-Base or R-Base or FoxPro system for data that you need to consume. But the reason that

you're consuming that data is to do some very heavy lifting with it, like whatever that happens to be, some sort of processing or data crunching or calculations that are really complex. I mean, you can imagine that some professor or scientist in some lab way back in the inner sanctum of some government system or, you know, government agency or university system or something like that, you know, is collecting all this scientific data on something. Maybe it's on, you know, galaxies or stars or whatever it is. And now this, you know, she wants to do something extremely complex with this data that's been collected over five or 10 years and figure something out. Well, I mean, okay, so this individual collected it in FoxPro because that's all they knew how to use. But it doesn't mean that you're going to use FoxPro queries to solve the heavy lifting of this, you could very easily justify

creating a domain-driven design-bounded context for how you're going to crunch this data to do some very complex, you know, create some very complex solutions around it. Somewhere in the bowels of it is just one of those DBF files that contains all his, yeah. There you go. But maybe maybe ddd decides well

you know let's not put it back into fox pro but you know the results let's put it into something that can be consumed you know globally maybe this is research that's being done that's going to benefit scientists all around the world and and uh so let put it on DynamoDB or something in Amazon, and we'll have it available on five or ten or whatever different availability zones. I don't recall. I mean, it's been a while. I apologize that my DDD knowledge is kind of rough, but it doesn't really talk about performance and scaling as a concern. Is that intentional?

Well, I haven't really... I think that my book addresses that and some of the later work around DDD addresses that. I can't say that I really know why that was the case earlier, but I think there was a pretty messy time, you know, around when J2EE showed up or whatever it was originally, you know, enterprise Java beans and stuff. And, I mean, I remember when it was difficult to get a contract or a job if you didn't have EJB on your resume. And like two or three years after that, you didn't want EJB on your resume.

You know, so there was like a time when maybe you didn't have so much control over that. I think that scale maybe in the late nineties, early, early two thousands wasn't as big of a deal until kind of the, you know, the.net boom. And then, um, um, right around that time, things were needing to scale a lot, but even think back to Amazon in the late nineties, right. I mean, it was just, it was just a concept and, you know, probably like selling a hundred books in a day was a huge win for Jeff Bezos. So what was really needed to scale back then? Not that much. But then the Internet comes along, and wow,

we've got all this potential for drawing people from all around the world to a single web property and selling them stuff or teaching them stuff or whatever. And it just kind of went off the charts from there. And that's when scalability and performance became very important. But I think that was probably near, that was starting to happen probably around the time that Eric may have been finishing. It's an interesting question.

Maybe you can ask him that. But I don't think that it was such a big, important thing. Although what's interesting is the scalability and performance things with Amazon ended up needing to use and that Pat Helen wrote about, you know, in Life Beyond Distributed Transactions, that paper. By just ensuring that you design your objects in a specific way without creating large graphs of connected objects, then you stand a good chance of scaling and performing and doing a lot less garbage collection. So let's talk about that. I think that the rule that I'm familiar with is something to do with eventual consistency. So yeah, that I think that's sort of been labeled rule four, at least that's how it ended up in my book. So the first rule of aggregate design is use aggregates to protect true business invariance. You know, there may be this temptation to model an aggregate for convenience.

And so we start thinking about this kind of large cluster like, wow, you know, well, if I have a direct object reference to this object or to this tree of objects, you know, then I can just navigate through and I can do these things really easily. And that is pretty much how, I mean, not very large graphs, but if you, if you read Eric's aggregate guidance in his blue book, you'll kind of see that, you know, where the cluster of an aggregate design is a bit larger, not necessarily extremely large, but larger than what the current guidance might be. But again, he wasn't necessarily even trying to teach, you know, is this going to scale or perform?

He was just trying to demonstrate what the general pattern is for. And the general pattern is for protecting invariance. So if there is some data related in this subsystem or bounded context that you're modeling, and data item A changes, and data item B changes. And when those two change, data item C needs to change in a way that's closely related to those other two changes. And the business has a rule that says those need to be consistent constantly, right? Then those have

to be persisted in a single transaction. So that behooves you to, in some way or another, cluster those objects together, whether A, B, and C are just attributes on a single class, which is really easy to do, or if A, B, and C are each attributes on different objects, right? But when those change, they have to change are each attributes on different objects, right? But when those change, they have to change together and be persistent together, then the aggregate pattern is meant to do. That's first and foremost, you know, the motivation behind the aggregate pattern. And then, of course, there is the convenience of navigation. But when that convenience works against performance and scalability,

well, then you need to drop that because, well, you have to scale and perform. That means that you have to keep these things together, no matter how micro your microservices are, right? These things need to be grouped together. And I feel like maybe the problem where people say microservices are horrible, it's because they've split these things. It could, yeah, it could well be, yeah, that they really need, they feel this great need

to employ distributed transactions to have everything consistent because, yeah, they've just modeled their aggregates incorrectly. Or it's just not consistent, right? Yeah, it needs to be, but it's not. to have everything consistent because, yeah, they've just modeled their aggregates incorrectly. Where it's just not consistent, right? Like it's, yeah. It needs to be, but it's not. But then on the other hand, I mean, it depends.

But generally speaking, ask a domain expert, when does this need, when do these two pieces of data need to be consistent? And if you ask enough questions around, they may say immediately because they're used to hearing that immediately is possible. But when you show them that immediately is not such a great idea in this particular case, you might find that seconds or minutes or even hours of tolerance between consistency is actually possible. So that's a big difference from must be transactionally consistent. And there are definitely areas in a lot of systems that must be transactionally consistent is a very real requirement, whereas we can relax that, you know, to a lesser or greater extent across other pieces of data. And that's where potentially that those two concepts are separated by bounded context, they're in two different contexts, but it could even be that they're in the same context, they just don't need to be transactionally consistent. So that's where the, you know, that's where the, that's where the complexity of and the diligence comes in with trying to model these concepts because figuring out those boundaries sometimes can be a challenge. around those becomes unnecessary because if it's possible to persist two loosely related

entities or three in a single transaction, right? If it doesn't cause transactional failure because multiple users are trying to use the same one or more of these same entities simultaneously, it doesn't matter. So it's not like DDD is trying to get you to use a certain set of patterns to prove that you're DDD-ness, right? Oh, we're using the aggregate pattern, therefore we're DDD. That isn't the purpose of it at all. It's really, it's a problem. It solves a particular set of problems. and if you don't have those problems don't use it. Yeah, I was interested in it for the idea that it might provide some of these guardrails

and guidance around how you might cut things up and I think that that is a great example how the consistency within a grouping shows that those things need to be together. What about when they don't need to be consistent? Right. Then you can use a domain event as a, you know, let's say a sort of reified or wrapped message that says this happened.

And when the system or even the same subsystem, the same bounded context sees, oh, that happened. Now I'm going to update or modify something in reaction to that. And so that is eventual consistency. So we've just kind of jumped from rule one to rule four. And in between that is rule two, that is simply design small aggregates, right? What's a small aggregate? Well, it's not a big aggregate. But I mean, I know that's a little tongue in cheek, but you know, really what it amounts to is do not design your aggregates to be any bigger than is required by the business rules to keep data consistent. That must be consistent, right?

Transactionally consistent. And then the third rule is reference other aggregates not by object reference, but identity reference. So now we don't build a graph, although we can navigate a graph through IDs if we need to. We are purposely breaking those connections so that our aggregates do stay small, right? Hopefully just one entity, even if possible. And then the, you know, those guardrails, the one to four, you know, set there of guardrails is keeping you in a pretty safe zone. So do you think that microservices are taken to an extreme? Yeah, I think so. And I've talked a bit about this. And I have not worked in some of the areas

where some of the guidance about microservices comes from. And I will say that there are at least a few, if not several individuals who say very, you know, outrightly that a microservice should be no more than 100 lines of code. And to me, that's just is like, you know, I mean, I inside I roll my eyes, right, if not even physically. And I, and I just say, yeah, but, you know, one of those responses, Because then if my life, what's that? That sounds insane. A hundred lines, even in the most concise language. Yeah. I mean, what does that actually mean? It probably means one entity or not. Maybe you don't even think in terms of entity. Maybe it's just, I don't even know. But yeah. But these are in environments where there could be tens of thousands of microservices. And I am not joking, like, literally, to unplug any of them because it could bring the system down or a portion of the system down and you don't even know that? What does that sound like to you? Sounds like Skynet from Terminator.

Well, it's a distributed monolith right i mean yeah that is the situation we get in with a big ball of mud is we're afraid to touch anything because if we touch anything it might explode and so the the organizations that are developing these kinds of 100 you know max 100 lines of code microservices are you know they're reaching this this point where they're really just reinventing the monolith that turns into a big ball of mud, where if I touch this, man, I could, you know, I could break something for months. So instead of touching anything, we just decide, you know what, it only costs four or $500 a month to keep each service running. Let's just keep them running. Now, how many poor nations could get fed by not doing that? I mean, just think about if this trend were to be global, totally prolific, and there were

hundreds of thousands of organizations doing this, and they all didn't understand their system well enough to touch any of those, and they keep paying amazon you know for more and more or whoever it is microsoft or whoever you know four or five hundred dollars a month for these tens of thousands per you know of of microservices per organization right but on a global scale and that that is pretty scary conceivably you could use something like Amazon Lambda or serverless so that all of these things like, you know, spun down and spun back up. But I think just the maintainability. But how do you know which, yeah, but how do you know which Lambda to unplug too, right? It's the same.

Actually, when you think about Lambda, that is the 100 line microservice or less. Yeah, it definitely fits that model, right? Where you have a function. And I mean, I think it could be great for like glue or, you know, just for massaging something. But to build an entire system at that level, I mean, I have a hard time picturing it, to be honest. What it tells me is that we need a lot better monitoring and system, you know monitoring and system discovery tools

where, okay, if we're really going to do this, I need to know, has this microservice processed any data for the past seven days? And if it hasn't, can we prove why it hasn't? Is it because it's no longer receiving messages? Is that because it's no longer used, it's no longer receiving messages? Is that because it's no longer used? It's no longer relevant? Or is it going to be relevant again next month when a particular offer is run again?

Yeah, and it becomes hard to point at, I guess, like business value and deliverables, like the service that you're working on. You know, it feeds things from one other thing to one other thing, and we're not even sure if those are used and and so what i'm saying is it could well be that you get into a situation where that is really the only practical way or one of the very few ways that you can work in a system like this like i mean let's just say i don't know if this is the case, but let's say Expedia, right?

Or, or, you know, hotels.com or whoever is just throwing all these offers together on a daily basis and, you know, escape winter, get out of the heat of summer, do, you know, whatever season it is, they've got, you know, umpteen different offers to make. And you just have to keep deploying these services to make all these deals work together and close them and get them paid make. And you just have to keep deploying these services to make all these deals work together and close them and get them paid for and then get them booked and everything. And they're so different or slightly different from each other that you can't really reuse anything that's there or very little of it. And so it's just like, okay, let's keep knocking out these 100 line lambdas or whatever. But if you're going to do that, yeah, I mean, just think about the ecological footprint of that.

It's an interesting use case. I mean, I guess you're saying it's like an anti-use case, but yeah, like Expedia, because each service could be very small, but it does have its own, like, like it's very well defined. It's interface, right? It's like, all I do is figure out if it's time to offer the Easter special or something. So like it is contained in a way. Yeah. So, you know, I don't really, I don't really know where those apply, but here's my guidance with DDD is, okay, create a bounded context. If it has 10 or a dozen entity types in it, that's really pretty small, right? Prove that you need to scale any one of those entities off the charts, right? Let's say that 10 out of the 12 are just pretty simple and they get used, you get used from time to time or whatever it is.

They perform fine in this single deployment that we have of small bounded context. But two of those entities or aggregates are just getting hammered constantly. We even have to use a completely different storage mechanism for those because while Postgres works for the other 10, you know, it's been proven that we have to use something, you know, Cassandra or Dynamo or whatever to make these other two kinds of entities perform and scale. And so we can prove, okay, we need to break these two out. So we're going to take these two and create smaller microservices just for them, but they are still logically part of the same bounded context. But I haven't overcomplicated things by

automatically assuming that I need to break up all 12 of them into microservices. And then by the time I have, you know, 50 bounded contexts in a whole system solution, I've got, you know, upward of 700 microservices, you know, these small microservices to manage that when in fact, maybe I could have 60, right? Because 50 altogether, but these 10 have to scale in different terms or their rate of change is different among the other parts of the bounded context. So it makes sense to break these out. So I'd much rather have 60 microservices than 700. But you're taking the, you know, I guess approach to show me, prove it to me that I have to break this into a smaller microservice.

And if you can't prove it to me, we're going to deploy these 12 entities or whatever it is, seven entities or five entities or 15 entities together. Because as far as we know right now, it'll work just fine. And it's pretty small as it is, right? It's a relatively small VM that we're that we're working in. You know, I heard, I think it's from Google saying that, like, when you design something, you should, you should design it so that it can scale to like 10x what you plan. But if it needs to go to 100x, like it's going to be something completely different. So don't even worry about it. But again, if, if you think it could do that, you know, then go ahead and design the aggregates with those four rules of thumb. It's not going to hurt anything. If, if it, if it only, you know, if it goes to 5x bigger than, than you first built it for, I mean,

it's not like you failed in some way, you're still in very good shape. But if you can now scale to 10x and perform to 10x, because of some early decisions you made that I think that's pretty good, or at least be in a position to refactor when you can prove that you need to do that. But that's just the dangerous thing, though, is if you don't have those, like you said, 10x ideas on your mind up front you may not you may make enough mistakes along the way that you won't easily be able to do that when it's needed yeah you don't want to paint yourself in a corner and so that if whatever you're making actually succeeds like you imagined then then it doesn't actually work like yeah which is actually far more the case that it you know that things can things can't scale. And that's why, that's why, you know, a lot of fortune companies right now are in a very bad situation where they're scrambling to try to get, you know, on the cloud and they're scrambling to try to make things scale. And even really the biggest problem with them is they just can't make changes fast enough.

Because again, with that, I touch this and it's going to break something. They get to the point where they can only release once or twice a year, maybe three times a year. How can you compete today in that environment when you have startups that are on the way to dethrone even you know the the kings of of the industry that are technology companies like i'm i mean these are companies that made their billions on technology and they're in trouble yeah because the net because the startups are more nimble they can move more quickly and you know because you can gather these metrics right if your velocity of development and releasing things and gathering feedback, like they know, they know because they see, they, they see their, you know,

they hear their, their customers complaining about, you know, this doesn't work. And when are we going to get a fix and, or when are we going to get this new functionality and it, and they can't deliver it in in internet speed well we're uh running out of time here um is there anything else we should cover well um that's an interesting question i yeah i think i really want to let people know about my lingo platform that's v-l-i-n-g-o vlingo uh which is a lot about lingo, right?

So the language of supporting the languages of domain-driven design. So Vlingo platform is being developed for the purpose of developing DDD-bounded context in a very DDD-friendly platform and ecosystem. And I don't really know of any other platform that, you know, while they may say that they have delivered on DDD or that they want to deliver on DDD, I don't know that they've really accomplished that. And I think that, you know, I'm maybe not the very best person in the world to determine whether something is good for DDD or not, but I think I'm probably right up there. So I want people to take a look at Vlingo. It is currently far along in potential release candidate stage for Java. And we're also, I have a team working on the.NET side of things.

So the idea is you can spin up bounded context slash microservices that are reactive using the actor model through and through, right? So every single component, which right now there are about 10 components in the Vlingo platform and it's growing, it'll be 15, you know, for well before the end of the year. And all of these are running in a reactive actor based message driven, event driven ecosystem and event-driven architecture. The patterns of DDD just snap in very easily. I'd like people to take a look at that. It's open

source so people can see how these concepts shake out in code. It's open source. GitHub.com slash Vlingo. V-L-I-N-G-O. I'll put a link as well in the notes. And I'd love to have more contributors.

I have some contributors, but as the platform grows and becomes more popular, it sure helps to have more developers. And so what I'll say too, is if anyone, like in a, I hate to put it this way, but a more depressed economic environment, like maybe Eastern Europe or somewhere like that, or even Africa or other European countries that don't have, you know, quite as demanding salaries as, um, as the United States and Western Europe and so forth. I would love to talk to you about working with me. I, I am, I'm bootstrapping this whole, um, development cycle and working with volunteers right now. But if I can afford to hire, um, uh, folks at a, at a rate that I can afford as a bootstrapper, then I'd love to talk with them.

That's great. So you're looking to put some people on payroll. So if people want to learn about some of these concepts, they can reach out to you. Well, thank you so much for joining me for this conversation. It was a lot of fun, Vaughn. Okay, yeah. Thanks a lot, Adam. Really appreciate it.