Domain-Driven Design & Event Storming, with Jakub Pilimon

Episode 103 · 1:04:10 · SRT · archive.org · all Tanzu Talk

All right. Well, usually I have some inane banter, but we'll just start right into it, because I've been looking forward to a little chat here. Why don't you introduce yourself? Hello, everyone. My name is Jakub Pinimon. Currently, I work as a principal technologist, and some people call this role developer advocate, and I work for Pivotal right now. I'm from Poland, and here people use the name evangelist for this role. I think it's probably due to very religious context of our country. That's my guess. But after all, the term comes from religious evangelism. My question is, how about Netherlands and US? Do we use the term evangelist still there? You know, I think it's mixed. I think in the Netherlands, I don't know what they would say. They probably would. Yeah, I think advocate is a weird, this is a very, not contentious, but I agree. It's confusing to know what to do. And I was talking on one of my other podcasts. Like, I'm not sure. I think maybe we're supposed to call ourselves strategists now. Have you noticed this trend? There's all these people, you'll see, it's these people at vendors called strategists. I think the issue is, if you use a command prompt, you are an advocate. And if you don't use a command prompt, I think you're a strategist, how you distinguish between the two. So I think I am a strategist, and I think you are an advocate. I still use the command prompt, so I'm still an advocate, right? Anyways, I don't like the word evangelist, to be honest. Yeah. So I see our role more as someone responsible for sharing the potential of some products, methodologies, et cetera, et cetera, right? In my case, I try to focus on architecture design. And only after that, spend some time actually talking about tools. Before Pivotal, I used to work in various companies like immobility, e-commerce, fintechs, amongst others. And this was a wonderful time. Being an independent consultant

allowed me to get to know different problems, different domains, get familiars with different specific domains. Hence, my interest in the management design, by the way. From time to time, I work as a trainer, too, focusing on the management design and architecture. Yeah. Yeah. Well, you know, other than working together and being on the same team, one of the things I've been talking with you about recently is I have this, well, first of all, there's this issue of what happens to enterprise architects and all of our glorious future of cloud native and DevOps and agile and SRE, whatever, all that stuff. Because I don't think any of the literature uses the phrase enterprise architect. And yet there's a lot of them and they seem to provide a role. And so one of the things I was thinking about, I've been thinking about over the years, it's like, I kind of know what domain-driven design is, sort of. And we'll see how much I know. But it seems like at a large organization, an enterprise architect is well positioned to define those, if indeed they are skilled at it. And so to that end, I mean, maybe eventually we'll get to that. Like, what is domain-driven design? What is this? What is domain-driven design? That's a tough question, to be honest. I have read like three or four books on domain-driven design. I still, I'm not sure how to define this term, but let me try. So nowadays, critical factor or thing that defines the success of any IT project is understanding the problem to be solved itself. As the Eric Evans, father of domain-driven design, he once upon a time has said that the biggest complexity lies in understanding the domain itself, which is the system to be designed, which problem to be solved, etc. And I have a feeling that our industry is great at technology. Like you said, cloud solutions, continuous integration, continuous

delivery, we are able to push from an idea to production in days or even hours, right? But what's the benefit if I push the wrong thing or not suitable thing, something that is misunderstood? And domain-driven design helps solving this problem by constant knowledge crunching and creates the shared view. Or as someone once upon a time has said, the shared repository of knowledge across the whole organization. And that's what domain-driven design is to me. Because sometimes there is no point in writing any software in the first place, and there has to be a problem which we intend to tackle, right? And domain-driven design tries to distill this core problem, focus on it, and do our best in this specific place. So that's my take on what's domain-driven design. It's not code, because code would be just a side effect of this process. I think that's what we're going to do in the first place. One famous guy from domain-driven design community, inventor of event-storming, he said that software development is a learning process, and working code is just a side effect of this learning process. So this is what I think about domain-driven design. I think he deserves a huge credit for stating as such, it's an iterative learning process during which we build this common understanding of the problem space. And the code that just works is a side effect of that process. So, yeah, I know it should be maybe defined in two sentences, but I am not capable of doing so. No, you can't define something like that in two sentences, right? Like, it would be, and I think because, like, you know, for the, well, there's two ways of defining things. I'll use an analogy, right? Like, I think going back to, like, how you, we, us, we would describe what it is we do, I've finally settled on a way to tell the normals, if you will, people aren't

in the tech industry. That's very concise. It's basically like, I don't know, I'm a company spokesperson. And like, everyone's like, all right, great. Now we can go talk about something else. Because that's, that's the most easy to understand tangible part of what, what I do and the other people on our team do is like, we go out and talk to people. Now, if you are actually like one of us or someone in the tech industry, like that would be a completely insufficient thing to describe, right? There's all sorts of other things that we do, but it's easy to explain. And I think similarly, if you were going to explain like programming to someone, you would be like, ah, you write this code and it tells computers what to do. And it makes the software, it makes screens that people interact with that do things. That's what programming is, which would be a terrible explanation if you're actually a programmer. And like, I think, yeah. And then the, the, the longer explanations are always that as, as you were kind of going over there, uh, I, confusing is the wrong word, but like, I always found this frustrating on, when I was younger, but I feel like when you ask what a complicated thing is, the more difficult it is to define, the better someone has a grasp on it. It's kind of a very like Eastern philosophy approach to things. But because what you do is you like, you've suffered through all the insufficiencies of the thing. So you're like, ah, I don't want to make any promises that it solves things. Basically like any thought technology in computers. I think the ultimate definition for an expert is it's a lot worse than what we used to do. Yeah. It's like a solving one problem and causing two more problems, right? Exactly. And you know, when, when I, when I've looked at, especially when you were just going over it, I don't know if, I don't know if I've ever connected these two things so much, but when I, when you're just going over, uh, uh, the main driven design or triple D or DDD, I don't know what people call it, the insiders, but like, it reminds me a lot of this sort of, um, business strategy

theory called jobs to be done, which is nothing at all to do with computers, but it basically means instead of thinking about yourself, what's an example, the classic example of all things is a milkshake, right? And so instead of thinking of yourself selling milkshakes to people, you're just a milkshake seller. You actually go and study what people are doing with your milkshake. And this is why it appeals as the technologists. And if you study them, you find out that a lot of people use a milkshake. Shockingly, they buy it in the morning and they use it as a quick substitute breakfast that fills them up. And so once you figure out this job to be done, that allows you to perfect the milkshake, right? And it may not actually be like a milkshake that a kid or a fun adult looking for a good time would buy, but you can make like a smoothie, like milkshake-y thing. And it all. And, and when I read about domain driven design stuff, it feels like there's that similar, as you were saying, constant learning of like, what is this thing we're actually doing? And therefore, how would we organize around providing it or something like that? I don't know, but, but at that point, after that, it gets confusing. So maybe that's a good start is like, I guess, ironically, given that you do a vent storming and domain driven design. What are the activities that one does when they're doing domain driven design? So first thing first, I really like the connection to milkshakes. And one of the, I think one of the outcomes of this milkshake research would be, Hey, sometimes those companies, they don't even need milkshakes. We won't sell them with milkshakes or they want to buy milkshakes. And then they don't even know that maybe exactly. Exactly. And like, in that case, the job to be done is like, I need a really quick, cheap breakfast that I can pick up on the way to work. Right. And that tastes good. Exactly. Exactly. And it doesn't have to be necessarily milkshake, right? Exactly. Because

everyone does milkshakes. So maybe I will do milkshake as well. But in my context, something else would have been better. So this is what I think about domain driven design. And describing it with milkshakes, as you mentioned. So you also mentioned that programming is hard to, it's hard to describe. I think that's correct. But also programming has a good metaphor for us, for all of us. Like, even though we are not from technology industry, you can understand the word programming because it, we have metaphors that will help us understanding and understanding this word. Whereas domain driven design doesn't have those metaphors built yet. And it's hard to understand even by people who work at technology or a business because it doesn't have a good metaphor to connect with. So that's the problem with domain driven design. That's my take. Also, you have asked about activities, right? That's right. So it's not like there is no ceremony. So we don't, you don't necessarily have to do each sprint or each iteration, a specific thing like, hey, I have to do some kind of a knowledge crunching each day at 12 o'clock because that's what process says. Right, right. So things that may help you is doing conversation with the business owners. And conversations are the most popular ways of gathering knowledge, right? But, however, those conversations and meetings share a common problem. They often turn into something messy without any visible effect. Right. If there is any visible effect, so most probably it's the one written down by a requirement analyst or business

analyst, EA or whatever we call this person. And those documents are just snapshots of this person's current understanding of the actual conversation and the actual problem. It's a snapshot of their understanding at the time of speaking. So it's already subjective, right? And then there is this process of developers reading and understanding this document. So then, therefore, the code is a snapshot of developers understanding the document at the time of implementation. Right. So we have these two layers of miscommunication, two layers of translation. And that can cause huge problems because after all, we can deliver things that are not even close to the initial idea of the business owners, right? Yeah. And just as a side note, and not to distract us too much, but that's an interesting classic problem in programming is, kind of to borrow some information terminology that I barely know, it's basically like the fidelity of information between point A and point B. So when you go from a business analyst to a developer, what is the loss of that requirement that you have, right? And you're like, you're pretty much guaranteed that there's going to be some loss of information and some misunderstanding. And like, I don't know if, I don't know if we really model that in development. And I guess the hack around that, that we have a lot is like, don't have them be separate people, but whatever. So, so anyways, back to the, uh, that we'll, we'll emerge from the footnote and, uh, go on with the normal course. Um, so we tend, as you mentioned, we tend to create those layers of translations. Um, I, I think about this as, um, we have this game in Poland. I don't know about any other country, but I, I think, yeah, in UK, they call it Chinese whispers. Do you know it? Hmm. Or like a telephone?

Yeah. Yeah. Yeah. So it's, uh, the direct translation from Polish would be a death phone. Um, I think it's called Chinese whispers, but it's exactly what's happening with those business requirements gathered at some meeting and then written down on a piece of paper or a nice spreadsheet or a nice word document or whatever we use. And then, um, by it's taken by developers who try to understand that and translate into code. But luckily there is something that can help you. Uh, so Alberto Brandolini, he proposed in 2013, I guess, a technique called event storming, because after all, how do we actually perform this meaningful conversation between stakeholders and development team? And even storming is a technique that can help you. It's an exploratory exercise built around conversation, but with visible outcome, because we have tons of sticky notes with domain events, with hotspots, with misunderstandings, without, with understandings, with risk written down on those sticky notes. It's a straightforward and understandable. I would say it's understandable by anyone. So it's a straightforward technique, understandable by anyone. And this common vision is built. Common language, so-called ubiquitous language. It's, uh, it's a term that is, uh, that's coming from DDD community, ubiquitous language. So the language is spoken by, uh, everyone in our piece of, in our piece of model, by business owners, by QAs, by DevOps, by code, especially. And this, uh, this ubiquitous language is present on those sticky notes. Uh, in our industry, I have a thing that we have a nice misconception that the only important language is our programming language. Uh, but after all, we should focus more on the business language and let this language flow starting from domain experts minds and finishing in

our working code, which is understandable by the domain, by those domain experts, because it speaks the same language. So even storming is the technique where you gather those people, business owners to people with answers and, uh, technical people. So people with questions and you build this common understanding. Um, it's, um, it's a, it's a great technique because it allows you to build a common, common language, which is not focused on technology. So the domain experts can really, uh, help us gathering this knowledge and understand that. So, so what's like, uh, what's like an example? Like let's, let's pick a domain. Like I know in your presentation, you always use credit cards, but maybe there's something better. Like what's a, what's a thing domain is the wrong word in this context, but you know, what's, what's a area of business or something we could pick to have some. So let's say, I don't know, for instance, Uber or taxi, something like this. So, um, if you focus on those behaviors and domain events, you would have a tons of sticky notes that would try to, to, to be enforced in the timeline, in the timeline. Like, uh, one sticky note would be a taxi ordered, right? A car was ordered. And then there should be some separate process trying to match the available driver to your order. And after some time, there is an event, Hey, um, a taxi driver match to your order. And this creates a ride for instance, but the ride can be still canceled. So we have, um, an order which says, uh, right canceled. And then the, the drive may not be canceled, but the driver may not arrive from whatever reason it was. Maybe he had an axis and stuff like this. So speaking about those events allows you to find the holes in your model. So it allows you to tackle the model and allows you to, to, to think about your model and your business from a different perspective. It allows you to ask questions, questions, which are not related to technology.

So that, what would be, um, of course, and during this event storming session, you don't have like three or four sticky notes as we just used for taxi. Most probably we have like 400 or 500 of them. And you try to, to, uh, to find misconceptions between two different people or two different, um, departments, because during the session, you have people from coming from different departments. Let's say, um, um, in, in taxi domain, you would have people from, um, customer service or driver service. And they will think about an, about the, uh, about a term called order in a different way, right? From a customer service perspective, an order would be something that's related to a customer from driver service would be something, uh, related to a driver. So we have one thing that's in fact, it represents two different things in the real world, in our problem, in our problem space. And you have to find those, those misunderstandings during this session, because it allows you to, to, after all, to build a model, which can grow independently in the customer service department and in the driver service department. I'm just, um, I don't know if there is such a thing as a driver service. I'm just, you know, um, trying to... You're, you're, you're inventing your own, uh, Uber service, uh, car service. If it would be, if it was, uh, a bookstore, online bookstore, uh, that's easier. You have people from a warehouse and they care about size of the book and maybe the number of the books you have in your inventory. Uh, there will be people from taxes. They care about the price and the tax. They will be people from product catalog. They care about the title, people from shipping. They will care about, um, I don't know, most probably the wave of a, of a book. So we have different perspective on the same thing. Um, and you, it's, um, if you model this in one place, it's going to be problematic because your model will be, uh, tightly coupled to a different,

um, different requirements coming from different perspective. And then there are those different perspectives that can be in clash. They can be, um, causing problems and you are not allowed to, to, to, to grow independently of different departments. So yeah, that's the, I think the first way I encountered domain-driven design was it's almost been four years that I've been at Pivotal, but I guess like almost four years ago. And, uh, like, I think it was like Matt Stein, who was talking about, uh, you use that to figure out microservices. You would have, which, you know, now that I'm thinking of it, I wonder if that was sort of like, uh, retconned into microservices or, you know, which one was the, the horse in the cart? No, wait. Yeah. There you go. With the chicken and the egg or whatever. Yeah. Uh, but you know, what you're touching on was, uh, um, what, what would you call it? It was like a taboo of software design, which was, it's okay to have multiple entities or, or objects that are the quote unquote, the same thing, because the way they're going to vary is by the, the group using them. Um, and so as you're, as you're going over, right, like a book to the shipping department is different than, or I would imagine is different than a book to the recommendation engine or something. Um, and that, I think that was an interesting, like, well, what if we don't follow that rule of, uh, what's the old rules? Uh, not, you aren't going to need it, but, uh, don't repeat yourself. Like what if dry doesn't actually matter or matters less, which is, which is intriguing. So the thing is that even though, um, that's my opinion, uh, even though the code looks the same in two different places, it doesn't mean it's, uh, we are violating this. Don't repeat yourself principle because, uh, it can grow, right? It can grow. It's always easier to, um,

to merge it afterwards, afterwards, if you don't need it, then split it afterwards. If you have like, uh, one model for two different things. Hmm. That's a good long-term view. Yeah, that makes sense. Uh, and, um, you mentioned microservices and Matt Stania. He has a great content on domain driven design and microservices for, for sure. Domain driven design was first, uh, was first. And, uh, I think it gets second law nowadays also because of microservices. Um, the thing is that those, those independent models allows you to have so-called polyglot persistence. So we can choose and pick your own tool for persistence of those different models, because after all, hey, they are different. So why not, uh, why not picking the right tool in a different, in a, in a different places. Um, and these are called bounded context. This is, um, I think most important thing coming from the main design community. And yet it's, uh, the most difficult one to describe, but these are those, uh, different perspective on the same thing. And these are great candidates to, to, um, to be used as separate deployment units. So right. Microservices, right. But you can go with monolith application as well. And, um, that's what I also always recommend for starter to have something which is called a modular monolith. So a monolith with those bounded context with clear boundaries. And it's going to be easier. I'm not saying easy, but easier to, to migrate to microservices later on if you, if you really need to do so. And these are great candidates because there's a, these are oriented, uh, around products, uh, around business capabilities. So, um, they should be autonomous, uh, which is the definition of my, of a microservice, microservice, right. And they

communicate, um, and synchronize state using eventual consistency. So that should work. And, um, that's why, in my opinion, the main design is getting a second lock right now because of the microservices hype, but, um, um, bounded context and those separate models from different, for different things were first. And then people just, uh, figured out, Hey, after all, we need the separate things which are separately deployed, separately scaled, um, should be autonomous. These are the same things that the bounded context are. Yeah. Yeah. Yeah. That's interesting that, that you mentioned like the, uh, uh, the transactional persistence problem, which, which is always an issue, right? Like basically like we were, um, we were doing some, some spring tour stuff, uh, I don't know, a month ago. And, and my, my little joke to tell with people is like, let's, when we have the Q and a part, let's see who the, how long it takes for someone to ask about transactions. Like, that's just always like, there's always someone who wants like two phase commit. And they're like, how do you do that? And then you're like, you don't do that. And they're like, okay, I don't know what to say now. Right. It's just like, it's just like this dead end. It's like, how, how, how do I fly? And you're like, you know, don't fly anyways, but it seems, and of course, I mean, you know, persistence and transactions and all that is always a problem, but it, it, that's another intriguing thing that if you're doing this event storming, right, you're kind of laying out all the events that happen to buy a book or book a taxi. Um, and then you divide it up into components or modulars, those being the domains. It's almost like it actually works out fine for there to be eventual consistency because those domains are separate enough that they kind of act independently and they can kind of synchronize with each other out of sync. Um, and I'm sure there's all sorts of problems with that, but that's another dimension to look at it is like, where are, where are the boundaries of minimal

transactionality? I don't know what that means, but like, where do we find that we actually need a transaction? And that seems like a line somewhere that, that you can draw as well. Yeah. So I have, uh, my, my heuristic, um, to find actually, uh, those boundaries is let's ask ourselves a question, how our business model or how our business would have worked, uh, without computers? Because after all, acid and, uh, atomic transactions are a thing that's, uh, that, that, uh, was developed by us, by developers, right? Before technology, there was an industry of let's say banking and they had to work without transactions somehow. Right. And they were distributed because there wasn't the central bank unit. Uh, bank was distributed. You had like several places to pick your money from and several places to deposit your money too. Uh, and after all it, it had to work somehow without computers, without transactions, uh, it worked in an eventually consistent way. Right. And nowadays also banks, they, they, they, they, they, they work in a eventual, uh, eventually consistent, consistent manner. Um, let's say I can overdraw my account. Is that a good word? Overdraw? Oh yeah, for sure. Yeah. So we can do it. That's in fact our business model. Um, I want you to overdraw. I want you to be able to take advantage of eventually consistent, eventual consistency, because I'm going to apply penalty or some fees. Um, I will earn more money because I'm eventually consistent. Yeah. I mean, to interrupt, I think, I think another good example is like, I don't know, maybe this is putting a, uh, a round hole in a square peg or whatever, but like credit cards are kind of an eventually consistent system in a weird way. It's just like you, cause you don't actually,

me, the credit card user doesn't pay the person. And then my bank account isn't reconciled at the point of purchase. It's just sort of like, there's this record that eventually I should pay it. And, and if I don't pay it, there are penalties. I mean, literal penalties for me not paying it, but it's not like, it's kind of like the credit card company is there to like cover the, uh, that time where, you know, the time where the transaction doesn't close. And then there's, you know, exceptions and errors get thrown that caused me to have to pay money if I don't do it. But it, it kind of allows this, uh, this fluidity of, of moving quickly. I guess there's like a credit limit, but I don't know. Anyways, that that's probably an easier thing to, cause I guess that's another thing built into the system is it's probably very rare that you have two credit card transactions at the same time, unless, unless you have like two of your subscription payments go at once while you're buying a jacket. But that would be very difficult for that all to happen at the same time. I don't know. Yeah. And, um, if you have those transactions and you have those multiple times, actually, maybe you are a fraud, right? So I can easily spot you. Yeah. Yeah. And you are trying to trick the system. Um, you are trying to get advantage of, uh, of my system being eventually consistent. And if I design my system in a manner that it's, um, capable of noticing the fact that you are trying to trick the system, that's fine. Right. And it's easier to model our system now in an eventually consistent manner, especially if we talk about, um, distributed system, there is no other way, by the way. Uh, but we, as, as, uh, technology industry, as, as software engineers, we tend to focus on those atomic transactions and we tend to focus on, Hey, what happens if this happens? And then if that happens, and then after all, after two minutes, if that's another thing happens. So we, we try to focus on those edge, edge conditions, whereas our business may be super

happy with 95% of them, of the, all the possible conditions and cases, um, being implemented and those 5% or 2% being done manually or even maybe I can lose money in those 5%. If that allows me to go faster to production with my 95% of, of, uh, features done and leaving those two or 5% of edge cases, um, for a future work, that's fine. But again, it's not our decision, right? It's, um, it's a business decision. So I would always, in the main driven design, I was, I would always look for answer in the domain itself, right? What happens if that, and what's the risk and what's the cost? What's the cost? So I, I distracted us here. Let's, let's go back to either the, uh, the taxi example or the book buying example. Like what, like what, how do, what, how do we define and what are the domains we have, we have in those examples? All right. So again, there's no such of like, um, um, silver bullet to, to define those domains. You have to, um, be present during this, uh, event storming session. And by being present, I mean, look at what, uh, people are talking about. So there might be people talking about, um, a taxi driver or another term like an order. We already mentioned order, and they will have different things in mind. The same, like we used, uh, with our book example, right? Um, so they will care about different properties of an order. Most probably people from claims, they will care about, um, a route, right? Of, of our right, because maybe the client is complaining about, um, the chosen route was too long and I paid too much, or I spent too much time in the taxi, uh, in the car, uh, whereas other people, uh, from customer service or from, um, you know, in, in, in the old days, there was this lady trying to match your order to a available

driver, right? Yep. Uh, there was this person trying to match, uh, your order to, to available driver. Now it's, uh, it's technology like Uber has its own engine to do so. Um, for this kind of a person or, or for this kind of a piece of, uh, of model of code, um, and all there would be, there is, uh, there's no order yet, by the way. There is, uh, a taxi available, a taxi driver available, and there is, uh, three customers waiting to be picked up at this specific location. And I'm trying to match something and I'm creating an order, but our order doesn't have anything when it comes to route yet. There might be proposed route, but it's just a proposed route, right? I can agree to this proposed route as a customer. Uh, and then there is something different at the end of the, of the, of my drive, the driver, the driver, he might have taken a different route because there was a traffic jam or the customer asked him to do so. Um, so an order for the claim department would be something different, um, from, uh, would be something different than it is to, to this customer and taxi drivers, uh, subdomain, I would call like this. It's easier to come up with, uh, with something when it comes to this book, bookstore department, because I'm not familiar with, with, with, with taxis and how they work underneath. But you would look, um, the heuristic is that you would look for, for people talking about different things and you would try to find misunderstanding between them. And they use the same term. Like product is something we sell and other people, other person would tell a product is something we buy because maybe in our company we do both, right? We sell products and we also buy products, right? We sell cars, right? We have to buy something to actually build our car. It's different department, the same world. Um, and that would be the first heuristic to, to try to decouple to, into those domains, right? Yeah. And I mean, tell me, tell me if I'm understanding this right,

but I feel like I've, I've, I've, I've learned a new angle on this is like, I guess I've noticed. So basically this conflict that comes up in event storming is used as a heuristic to find different domains, which is to say, whenever conflict comes up between like, Oh, I think a book means this and a book or someone else thinks a book mean that the, the first thing might be like, well, one of you is wrong, right? Like if it's within the same domain, you just might be thinking, you know, maybe you need to combine your two understandings or actually a book does not include a light bulb. So that's a misunderstanding of what books are, uh, unless it's a really funny book. Um, but what's interesting is the second thing in my mind is like, if there's a conflict, then that means they're talking about two concepts that are different enough that they would belong in different domains. So as like the facilitator of some event driven thing, you're basically like, Oh, we should look at this stuff on the margin, these conflicts and see if that helps us crack apart and find what a domain is. Yeah, so exactly. Um, that was a great example of this. Hey, you are wrong with this book because the book doesn't contain a light bulb. It can happen. Of course, because after all, even storming is a technique to, to share knowledge. So, um, if my knowledge is not correct and someone will, uh, tell me the truth, Hey, the book is something like this in this context, that's fine. What can happen as well? But most probably, um, those misconceptions will happen from people, between people, uh, that are coming from different, let's say department. I'm not going to say departments. It's a wrong thing, but, um, different perspectives, right in the ideal world from different departments, but, uh, in normal organization and regular organization, we have people that, uh, know something from their department, at least a little bit, uh, of something from the department they work closely with. Maybe they have, uh, they have a feeling that they know something about this department that

sits next to them does by accident. So they have feelings about things in the different departments. They have feelings about their knowledge in their department. And actually I can spot that during this, uh, during this event storming session and, and try to propose something. But again, it's not a heuristic is it's a heuristic. It's not a deterministic outcome that you would all end up with. It's not like, Hey, if you do eight hours of event storming, you will, you will come up with, uh, with nicely, nice boundaries of a software. No, exactly. I mean, kind of starting with the vague, ambiguous hand wavy stuff we were talking about, right? Like when, what you need is a tool to like discover something definitive. Right. So it's not like, like, it sounds like doing this process, like it's not, it's not prescriptive in what the end is. It's just like, how do we surface these, these things that then we make decisions about, right? Like you need some, some way of, uh, pulling up, dredging all this stuff from the deep, which is, or the shallow, I don't know, uh, which, which is always, uh, difficult. And then I, I guess, I guess also not to be all the negative case, you might also discover different things that are actually the same thing in this process and consolidate them. Yep. That, that can also happen. So another thing that, uh, uh, uh, that is very common and Alberto describes that as pivot events, pivot events are the events that, uh, are really important. For instance, let's say that we, let's, let's come back to our credit card example. So, um, I'm opening a website because I want a new credit card and I'm looking at different offers, right? So I have like, uh, let's say I have three offers, um, with different fees, with different interest rates, with different withdrawal fees, uh, and different, um, bidding cycles. Let's say I'm picking one of those and I'm signing a contract and, uh, I get my credit

card, right? Um, and my credit card engine, uh, the one that actually calculates the withdrawal fees and interest rates has to know about the actual values. What's this guy, what's this guy's withdrawal fee? Because he just has, we withdraw money. We have to apply some fees. So developers think about this as, Hey, I have a relationship from my, I'm talking about database right now. So I'm having, let's say foreign key relationship or constraint from, uh, my credit card to my offer, right? But guess what? Those two have different life cycles, right? So it doesn't really matter what kind of offer, um, you are pointing to. It only matters what kind of withdrawal fee or withdrawal of, or interest rates you have because signing a contract is a transition event that creates you, um, current snapshot of the offer and copies and paste that to your, to your credit card domain. And then you have this offer that has its own life cycle and you can actually delete that the next day because maybe it's not rental. Uh, but your credit card argument, it's still there with this, uh, with those values, right? So we have those transition events in which, um, things behave differently. Like, uh, after signing contract, I cannot change withdrawal fee in my, uh, in my credit card, right? But I can still change that. So these are called the pivot events. These are described by the way. I recommend you to, I recommend to read, uh, Alberto's book called event storming all of the knowledge, uh, that you need when it comes to even storming. It's there. Yeah. Yeah. So, so let's say we've drawn out. I think, I think you hit on a good example there. Two separate domains are, uh, a credit card offer and then the credit card when it exists for using it. Right. Let's say accounting.

Uh, is it called accounting? Something like this. Yeah. Yeah. Yeah. And, and one of them is just sort of like, here's our deals and our, our, you know, the promotion that we have for a credit card. And then once you're actually using the credit card, that's a whole separate domain. Right. And you don't want to have like the same schema or object or whatever for the credit card on either side. There might be a lot of similarity. And like you say, uh, you will probably copy over or reference, uh, the promotion when you have the real credit card. Uh, but you don't really, those don't need to be the same thing. And in fact, it would be very difficult for them to be the same thing because for example, you might want to say, uh, on a promotional offer, we would like to add some new stuff to it or take things away. And we don't want to have to like sync up with the real credit card when, when, for whatever reason, right? Like maybe eventually we'll sync those things up, but for now we want to keep them independent so we can evolve them, uh, on their own. So I don't know. I mean, those seem like two good domains, right? Sure. Yes. And, uh, let's imagine if you actually have this foreign key constraint and you want to delete the offer because it's not rental. And then you have, hey, I cannot delete this offer because two or three credit cards, uh, actually they point to this offer. So you have to do something with your data. So what do you do? Uh, so you mark this offer as not rental. So you add the flag and then you have if statements if you're in your code in all the places when you use your offer, if it's deleted because of the, um, of the rental thing, then imagine the, the, the, the degree of accidental complexity that you, that you are bringing to your solution, to your solution space, just because, uh, we didn't do our job during the analysis of the problem space, right? Yeah, no, that makes sense. So let's, let's see. We gotta like, so what do you call these three that you gotta, is the credit card like an entity or what, what's, what's the lingo for that?

Uh, it depends. So the ultimate answer of a consultant, it's, uh, um, so these two, they, they might be a different bounded context. Um, and in those bounded context, you build, um, you find your consistency boundaries. So we have already talked about, I need those two things to be changed in one transaction. Let's say if I do a withdrawal, always, I want to, um, enforce some business rules. For instance, a business rule says, um, I cannot withdraw more money than I actually have on my account. That seems like a valid business rule, right? Um, and also you have a rule saying, for instance, I cannot have more than 45 or 50 or 100 withdrawals during one week. I don't know why that's what our business wants, right? I'm just, uh, trying to think about different invariants. These are called invariants and you have to somehow model your code so that, uh, it changes the two, those two things in a strongly consistent manner. So we are consistent immediately. I don't want to change my balance and then in an eventually consistent manner, uh, change my withdrawals counter or something like this, because it might create a slight window, a time of window, window frame, um, in which our invariants may be, may be broken, right? Because there will be different people, different persons trying to do the same thing. And the, the, the second thing is not updated yet. So you try to find those, those things we have to, which has to be, which have to be strongly consistent, immediately consistent, and you model those as aggregates. So aggregate would be a tactical pattern from domain driven design. It comes from actually, I think, and maybe it's not a popular opinion, but it doesn't different from, uh,

object oriented design. Um, it's an object which aggregates different objects and exposes some behaviors so that you can, you can perform comments and you, you run comments on this object. You don't talk to, um, to the, to the inside of your aggregate. So we don't talk to different objects that your aggregate owns. You only talk to your root of your aggregate. So it's called aggregate route. So you perform commands to your aggregate route and your aggregate route is responsible for spreading the information to all of the objects that it has and to all of the objects that need, uh, those information so that I can change any, everything in one transaction. That means that you always change one for aggregate in your transaction, which also, uh, gives us, uh, brings us to a point in which our use case typically would look like this. I have an application service for my use case, let's say withdraw money. Uh, of course I'm simplifying this right now, but it would like, it would look like this. First line of code would be, I want to load aggregate responsible for withdrawing money from my repository. I want to perform subcommand on this aggregate and I want to save this aggregate. And it's it's aggregate, it's aggregate, it's aggregates responsibility to spread the knowledge, to spread the effects, uh, on all of the things that has to be changed, uh, in a strongly consistent manner. And then you have those aggregates and then they can also, guess what? They can emit those domain events say, okay, the invariants, uh, all of the invariants are met. I can withdraw money, which, uh, which means that the money was withdrawn. So aggregate, it accepts the command, checks the invariants. And if, if it's fine with the invariants, it's going to emit the event saying something has done. So the state has changed and different things in like different bounded context, let's say some

reporting the bounded context, um, or other bounded context, they can subscribe to those events in a eventually consistent manner and update some things. The crucial story, the crucial story of this process is that you find those things that needs to be changed in a strongly consistent fashion and you model them as aggregates in one bounded context. And then you have different bounded contexts and they need some information from other bounded contexts, but then you modify those different bounded contexts by subscribing to those events in an eventually consistent manner. Make sense? Yeah. Yeah. I mean, it's almost like when you need to have a transaction or something like that, you basically make an aggregate to handle it for you. If it's crossing all the domains and then that's sort of like your point of locking, I guess. And then the other thing I think that, the other technology that's sort of like key to all this is using an event driven model where, and maybe this is how transactions work really low level, but instead of kind of having a linear way of syncing things up, you're sending out events that other things are listening for and they can respond to and blah, blah, blah. But then that's another, another key to like this model of doing things is the way you're basically sending messages out to use old OO terms. And the thing that receives the message is in charge of doing whatever and saying that, that it's fine with it. Yeah. I agree. I agree. Especially when you said that, um, this is our locking point and you described aggregates as locking points because one of the frequent questions, um, asked by people who are introduced to this concept of aggregates and, uh, objects in domain driven design, if you actually choose to do, to do object oriented domain driven design, because you can do functional style as well. But one of the

questions is, um, how do I do, um, optimistic slash pessimistic locking? So how do I do a concurrency control? And it's actually pretty simple. If you have those consistency boundaries found and you model them as aggregates, aggregate is the point where you apply, let's say optimistic locking and that's it. That means that one person can change an aggregate in a given time. If there is a race condition, I'm going to throw an exception and that's it. So you, you, you do it on your aggregate level. And then, um, you have those different, um, you have those different concepts, as you mentioned, like, um, instead of changing state all of the time, I'm have, I'm having this log of things that actually has happened right in my journal because I can actually store those domain events somewhere. Yeah. Yeah. And then you can play them back and do all sorts of things once you have them there. I mean, it, it always seems like, I don't really know how file management works very well, but it seems like that's a shift that's been happening recently is that idea of journaling and logging things has, uh, you can probably hear my dog playing with that toy. She's a frequent guest star on all of that material. Uh, that's right. But like this idea of journaling and logging, like gets raised out of the lower levels up to the top of the application stack to handle distributed transactions a lot easier, which I don't really know what to do with that. But that's an interesting notion. Um, I think it, um, again, it's a, it's an old concept, uh, this generic concept that, um, that's now give that's, uh, that has been given a second law because of domain-driven design, not only because of domain-driven design, it's a great query concept. You have those events, uh, those logs, those journals in, let's say in any database, right? You have the thing called transaction log and it's actually a up and only right ahead log of your transactions that you write to your database.

Yeah, that makes sense. If you want to replicate your database, you just share your transaction log to a different database and say to this different database, if you want to be, if you want to have my state, just replay this transaction log. Here is the start. Here is the, the end. If you play it in the exact order as I did, you will have the same state, right? Um, so I can actually replicate my database by showing this transaction log. Yeah. Yeah. And then recover things from it as well. If it's, if, if, if your log is stored somewhere that wasn't damaged, obviously, but yeah, that's interesting. Like, like basically, uh, computers don't have free will. They're like very deterministic. So you can, there's no variability in replaying what they were. It should, uh, be the same thing. So, so then, so then before we wrap up, let's go back to the original question. So should enterprise architects be the ones helping define these domains? Is that, is that something we can, uh, a bone we can throw to them? Um, I think they should be involved, but to be honest, what's the point of, uh, having one person that's trying to think about those domains with, I mean, one person from the technology perspective, from the, uh, from our background, from, um, from development team, I should, everyone, I think everyone should be involved at some point, um, in order to distill those domains. Yeah. Well, maybe to reverse it, it's sort of like, it's, it seems like part of what, well, let me not use the phrase enterprise architect, at some point, let's say in a, in a large bank or any bank, you've got a lot of stuff going on. And it's almost like someone needs to coordinate. Here's, here's all the stuff so that we don't have like five different ways of offering a credit card. And, and the reason you do that is so that

not, well, one, it's not efficient, but also so that it's easier for other people to interact with that. Right. That like, if I'm, if I'm doing what I called earlier, the real credit card that gets used day to day, it's really annoying if I have to go talk to five different things or teams or whatever to reconcile what this offer is. So, and then those kinds of problems across any large organization that, that exists a lot. So it seems like something or someone should be involved in like, trying to kind of like make the domains of domains, not, not to foist, uh, the usual, like, uh, you know, team of teams thing and scrum of scrums and all of that annoyance, but it, you know, it, it seems like there should be some, it would be helpful for there to be some reviewing of like, have we defined all these domains in a way that helps each of them out? Um, and like, I don't know, that's sort of like a notion of what EAs kind of do. And it's not so much that it's like, this is what an EA should do is I feel like if they're a good EA, they kind of know what's going on in the rest of the organization. And, and to your point, they can participate in the session with everyone else, but they can kind of give that input of like, Oh, and then it goes over here and then it goes over there and like all of that stuff. I don't know. It might also be trying to find like a, uh, what would you call it? Not a, not a solution to a problem, but like a, uh, to find something for them to do. But it seems like something that that would map to what our, our, our sort of optimistic notions of, or, or, yeah, they should be for sure. They should be involved. Also, uh, the outcome should be somehow shared across the organization. Right, right, right. Yeah. I guess that's another good point is, is like the, the, uh, I, you know, people never liked the word governance, but there's a certain governance of like, now that we've determined these domains, we should probably not change them tomorrow. This is, uh, this is never going to work like this. Right. Uh, so it sounds

like a big design upfront, which, uh, you know, it's again, it's the same thing. It's, uh, our current understanding of the actual problem and our current understanding might change tomorrow because guess what? Our software development thing is a learning process, right? And we gain more insights tomorrow. And, um, what we discovered yesterday might not be relevant tomorrow, or there was a rapid change in our, uh, market that, um, forces us to actually redefine those. Um, and, uh, what I think about this is that, um, if you do proper analysis and not only analysis, but if you do proper architecture and by proper, it's always, uh, um, hard to describe what's proper, what's good, what's well-crafted architecture, right? Uh, my definition, it's not mine, but I heard, I have heard some, some time ago, this definition is that a good architecture is an architecture that allows you to postpone the, the important decision as, um, as long as you can. Yeah. Right. And allows you to change those decisions, right? Uh, if there are important decisions, I would like to, uh, I would like to make them, um, in the future. Why? Because in the future I will have more knowledge than I have currently. So my decision may be, may be different than, uh, than the decision that I would make today. And most probably it will be better in one week or in two weeks than it is today. Yeah. Yeah. It's, it's sort of like, uh, uh, to mix domains up, so to speak. It's like a, uh, uh, it, I think it's the contrapositive of, uh, an accounting term called a net present value or NPV, which is basically like, you know, money today is better than money tomorrow. Sure. And, and where, whereas the, it being the contrapositive, if I know if I'm using that term, right, is basically like knowledge tomorrow is more valuable than knowledge today or not valuable in the sense of like, I will know more. And so therefore, if I can, if I can act on knowledge of

tomorrow, that's better than acting on the knowledge that I have today. Uh, which, yeah, I mean that, that, that, uh, I had, uh, I, one of my old architect friends, he used to call this, uh, architectural runway. Like you want as long a runway as possible. And, uh, and it's, it's good to build that into the system that you have, uh, that flexibility, but yeah, I mean, your point stands, right? Like, uh, uh, I mean, tomorrow is maybe too short of a period, but you, you want your system to be able to adapt and change. And, and to some extent that requires some, some hygiene, I guess, like that flexibility has to be built into the system somehow that, uh, that it actually works out well. Like if we invent some new type of cash tomorrow, we don't want to, we don't want to have to like, have that reinvent all of the software that we use for banking. Exactly. Exactly. And, uh, but it requires us to somehow, uh, be able to get this knowledge or to gather this knowledge in the future. Uh, I have recently, uh, read about, uh, five levels of ignorance. Um, and it hit me because, uh, I haven't thought about this, uh, in that way. So five levels of ignorance, uh, the, the, the, the level zero is, um, it, it, it, it says that you don't have any ignorance in your thinking with me, which means, you know, that there is a certain problem to be solved and you know, every possible aspect of this problem to be solved. And you know that there are no more aspects. So in a short term, uh, in short words, a long, long story short, it's, you know, everything. Then there is a first level of ignorance, which says, because that was zero level. Uh, the first level would be, I know some things I know a lot, and there are some things that I don't know, but I know that they are there. So it's like known unknowns, right? Um, there was level two, which says, um, I have, I know something and I think it's, it's all of the

things that I need to know, but there are other things and I don't know about them. And then there is level three, which means, um, um, I know something and I think that there is, uh, that that's all. And I have no one to ask about what the, uh, is there something more? And the level fit is that I don't have any idea about the five level of ignorance. So I'm just totally ignorant. And, uh, yeah. And again, this, uh, knowledge crown drink and, uh, even storming sessions, uh, helps us to, to actually degree, uh, decrease the, the, the, the, the level of ignorance in our understanding of the, of the problem space so that our solution space, um, is flexible and can be changed, uh, because there was a, um, market change that we need to react upon. Yeah. Yeah. Like, like I was thinking with our credit card example, like, you know, debit cards come about and then you got to do something with that, right? Like, like that, that must've been, or, or even chip and pin or whatever, right? Like things evolve and it's just like, well, now we got to go revisit everything and GDPR, right? Yeah. Yeah. Even worse. I, I always, whenever I run into my, uh, you know, I, I talked to my, uh, my Americans, friends, friends who haven't moved abroad, you know, my, my fellow Americans are always like, Oh, be careful how you solve this privacy problem. Cause basically like GDPR means every page I go to now that I'm in the Netherlands, I have to click on a button before I get anything. That's as far as I can tell, that's what it means. Now I have to click on something. Yeah. From, from user's perspective. Exactly. Exactly. All right. Well, I, this is a good overview. I think, I think, I think this overview, like, as we started off with never, never complete or anything, but I feel like, I feel like now, if I went and read about the mind driven design, I would understand what the point was and the outcomes. And I would have a good grasp on it. And then, and then also finally, I was looking this up, you know, you're going over the five

levels of ignorance and I was hoping the food pyramid, uh, would fit in this. So food pyramid has four layers. I think it's like, let's see vegetables, fruits and vegetables, grains, meat, and dairy. I don't know. Maybe if you separated out fruits and vegetables, you'd have five layers, but there's also the five dysfunctions of teams. You remember that book? So you've got five there. And then in lean manufacturing, you have the five whys. So whenever you're solving a problem, you always ask why five times to go down five levels. And then check this out. Maslow's pyramid of needs, five levels, five levels. So there's something about five, something's going on there. I guess five is good because five is not one and it's not, you never use a two and it's definitely not three and six is way too much. So it's like that four is just weird, but it's this perfect number of, uh, analysis to divide things. Cause I think once you get to six or seven, it's too confusing. You can't keep all that up, but I bet you can keep five things in your head at once. Yeah. Five things is, uh, I think it's enough for me. It was even hard to, to, to keep those five things in my memory. My memory is limited. Exactly. I'm going to be on the lookout for this. What other things come in fives? Like there must be other things that like are, uh, set up in five areas. Well, great. Well, if people wanted to, uh, follow up with you, I mean, not with you, but like follow your stuff or see other things you've been working on, like, what would you point them to? Um, first thing, Twitter. So I, I tweet under Jakob Limon and I have a blog. It's, uh, p-i-o-o-o dot github.io. So those two things, and I'll put a link to those in the show notes, which will be at, which will be at pivotal.io slash podcast at some point. Well, thanks for being on. I think this is, thanks for having me. Yeah. Yeah. And, uh, as always, thanks for listening. This has been Pivotal Conversations. Now you can get the, uh, the past episodes and

browse what's going on directly. If you go to soundcloud.com slash Pivotal Conversations, like I mentioned about every Thursday, we post this at a pivotal.io slash podcast. And, uh, also as a reminder, we're going to be merging together the two pivotal podcasts, pivotal insights, which is always a great podcast. There's a lot of customer interviews and kind of going over, uh, usage of pivotal related things and stuff people are doing, uh, with pivotal. Uh, and that's going to be merged together with this podcast. So we're starting now to publish every other week between them. So, uh, if you're listening, uh, to the order, you probably heard a pivotal insights thing last week, and now you're here. And the next week you'll hear one. So you get the idea. Um, and I think eventually it'll all become Pivotal Conversations. So you'll have that going on. So don't get shocked and enjoy it. And with that, we'll see everyone next time. Bye bye. Bye.

Tanzu Talk · 🍕 Get more pizza.