What is domain modeling?

I begin exploring the process of domain modeling with a definition.

Transcript

What is domain modeling? Hello. My name is Eric Normand, and this is my podcast, Welcome. So today I am starting to record these explorations about domain modeling, about two and a half years ago, I started podcasting about the ideas I was exploring for functional, functional program, which eventually turned into groking simplicity. I didn't have a podcast before that. If you go back to the very, very early episodes, you'll see that it's me rehashing these ideas, trying to define them, trying to figure out ways of explaining them, and that eventually led to groking simplicity, which is all about functional programming, and one thing that happened in the development of groking simplicity was that I had a plan for three parts. The table of contents had three parts. The first part was all about actions, calculations, and data. Very fundamental skill. And once you've incorporated that you've internalized that, then you can move on to the next level of thinking in functional programming, functional thinking, if you will, which is higher order abstractions. Higher order functions as arguments, stuff like that. And that leads to stuff like map filter and reduce, and building your own concurrency primitives and things like that. And then the third part was another leap, which is that once you've started doing stuff in calculations for enough time, calculations and data, you start to, if you go through the door, not everyone does this, it's kind of a more advanced technique. But you can start to think about your program much more abstractly. You start to think more algebraically, and have a whole episode on that. If you want to search for algebraic thinking. And so that was what the third part was going to be about, this algebraic thinking. Basically thinking about your program and thinking about what the code, what you can know about the code without running it, that there's a lot that can be understood abstractly and working with that. So that got cut. The reason it got cut was a good reason. I was already mostly done with parts one and two and part, I was thinking about cutting it into three volumes. But talking with the publisher, they were skeptical that three volumes was the right way to do it. They proposed the first two go together, and the third one is separate. And the reason was that the first two form an arc from beginning like no knowledge of functional programming all the way to professional. If you follow through and you learn all the skills in there, you have everything you need to be a professional functional programmer, meaning you get paid to write in Haskell or Clojure or whatever. And this is empirically true, not specifically the book itself, but these are the ideas that I took from people I knew. And I could, I talked with them, I observed what skills they had, and I put all the most important ideas in the book. So if there was an idea that was, and those happened to be in the first two parts, right? So all that is to say that in theory, if you're already a programmer, you already know how to program, this will get you from no knowledge of functional programming to you can call yourself a professional functional programmer. The third part was something that was, that I think is very important, and I do think it's the next step, but not everybody gets there. Or maybe they get there, but they don't need to get there to start getting paid, right? So that suggests a different audience, so like in maybe a senior person, so it suggests a different book, cut it there. And that was also convenient, it was pragmatic because then I could be done sooner because I was almost done with part two, and the book could be released. And then I wouldn't have to think about part three until all of that was done. Okay, so that's what we did. And the book came out in April, and now it is the end of October, yes, the end of October, and I have recently resurrected the idea. I went through my notes, I've been jotting stuff down, trying to organize the ideas and the definitions. I'm talking about it in my newsletter now, so I'm talking about it here and in the newsletter. And I'm not ready yet to say it's going to be a book, but I imagine it will. I'm not committing to it yet. I'm waiting for the ideas to really crystallize into something I think is worthwhile. And I will know somehow, intuitively, that the idea is big enough, or maybe I'll never know, right? It's possible that I won't know. But I won't make it a book until I know that I will have the motivation to finish it, right? That I know that this idea is big enough and well-defined enough to turn it into a book, because it's a lot of work. But I'm perfectly willing to make a podcast episode talking about the ideas, and I'll probably do more than one. So in this first one, I would like to simply define domain modeling. Again, this is one of those things that might help me more than it helps the reader, but I think a good definition can kind of help you with the scope and help you pin down the idea more precisely. So that's what I'm trying to do. And I've searched what is domain modeling, and you get a lot of articles. There's a lot of articles about domain modeling, but none of them actually define it. So you kind of get an idea of maybe a process or what one might kind of look like. And I want to be more precise, so to me, my definition right now, it's evolving, right? Like even last week, I changed it completely. But a domain model has three things. It encodes information. It encodes operations on that information. So the information is relevant. So relevant information, it encodes, sorry, let me start over three things. One, it encodes relevant information. Two, it encodes operations, domain operations on that relevant information. And three, it defines invariance, the stuff that has to be true, regardless of what operations you do or where your data comes from and stuff like that. So if you have those three things, you have a domain model. And of course, that doesn't tell you much. It just tells you whether you have one or not, it doesn't tell you whether it's a good one or how to make one and how to make a good one. So that is what the book is going to be about. To me, the real benefits of domain modeling are all the benefits that are traditionally associated with software design as it's called. But I find software design often puts the cart before the horse. Okay, well, I wasn't planning on going here, but I will. I think this is an important topic. The software design, when it is defined at all and its goals are defined, will say something like the point of software design is to decrease the cost of maintaining or writing software. And so it's a very sort of cost-centric business-centric goal. And that's great. It makes it good for convincing business that we do need to invest in software design because then future changes to the software will be easier, right? And that's cool. But because the focus is on the cost, the cost is kind of a lagging indicator. Like, you don't really know how much it's going to cost until you do it. And then you can say, well, it took me 10 hours. You can estimate and there are kind of rules of thumb that are not proven but pretty good indicators of, you know, if you move this leading metric in one direction, it makes the cost go down. So for instance, it's pretty clear that good names of functions help you understand what you're reading, the code, like what it does. And so that helps you figure out where a bug is, for instance, or if you need to change something, it can make it clearer what needs to change. So software design seems to have discovered a bunch of these leading indicators that help this lagging indicator of cost of maintenance. So the leading indicators that people will cite are things like good names, the length of methods, code organization, the classes, and whether they are coupled and coherent, right? So leading indicators that can clearly help move the cost down, which is a lagging indicator. And that's good. I mean, I think that that's a, you know, it's fine. It's fine for what it is. But I find that the problem, the thing that's overlooked, let's say, is that this is all focused on the code, size of your method, the name of your function, what file of function is in, you know, how your code is organized on the disk, it's all about your code. And that forgets that your code has to model in some way the real world, that your code, you know, a person class is capturing some information about a person. And that, that actually has to correspond to like the stuff that a person can know about themselves, right? That kind of thing is taken for granted. It is simply taken as well, this is the class. Now let's move stuff around, move it to this class, make a new method that causes other things. Like, it's totally forgetting that there is a world out there and that your software has to model it. I mean, some small part of it, some small part of the world, what we're calling the domain, and then there's relevant information for that domain. And if there's one, one thing, one insight that, that I want to base the book around, it's that, that we can't lose sight of the importance of keeping a tight fit between the domain, the actual real world thing we're modeling. And what our code represents, what it, what it, how it, you know, in quotes, how it understands that domain. If there's not a tight fit, that is the, the biggest contributor to bugs, to poor understanding, to slowness of developing features, slowness of changing a feature, if some, if the requirements change. Again, all that stuff, that slowness, that cost, that is all lagging indicator. And I want to find leading indicators that are not about the code, but about the relationship between the world and the code. Okay, not just the code itself, and is it pretty, but what is the relationship between the real world and your code? And those boom, boom, boom, dominoes lead to the lead, the lagging indicator of cost. And I think that the, that, that fit between the domain and the model, the model is expressed in your code, is, um, overwhelms, you know, code quality, the cleanliness of your code. But if you have a, like a hugely nested if statement, it's probably because your model is not very good, not because you're messy and you haven't cleaned your room. You know, it's just your model isn't good. And so I want to, uh, I want to make a book about that. I mean, I'm not saying I will, but like, that's what, that's what, that's the idea that is central to, uh, to the book, to the top as, you know, the way I want to approach this topic. So the book, we'll talk about how to explore a domain, um, figuring out all the relevant information, the domain operations that you'll need, how, how those relate to the relevant information and constrain the design of it. And then the invariance and how those constrain the design and how to encode those, because I think part of the definition that I missed is that these are typically, these three things are typically encoded in a programming language, or, you know, maybe more than one programming language because you have, you know, systems that have, you know, they'll have SQL and, uh, and a back end language like Scala and, um, maybe another query language they have to work with, uh, and then maybe their tests are written and something else. Like, you know, the way we break up systems today is, uh, is usually multi language, but it's all of it's written down in programming languages, or it's not, and it's like in our head, or it's in the spec. So, um, we need to encode it somehow, in English, in our spec, on a table, or in our code, etc. So I think that's, that's good. That's what the book is going to be about. In modeling, how, what it is, the process, how to make it good, how to make it, um, lead to this decrease costs and maintenance, because I think that that is a good metric. Um, but if you don't have a good domain model, you're going to reduce the, reduce the ability to be, uh, to, to be flexible and change your requirements and things like that. Um, another thing that I also think I believe a good domain model can be a competitive advantage. So it's not just like, oh, we're reducing the cost of, of carrying software and modifying the software. But it could actually like open up new markets and, um, just have fewer bugs and you know, it's, do, do magic for the user. And I want to explore that too. So well, see you in the next episode. My name is Eric Normand and I've been exploring domain modeling today. And please subscribe. As always rock on.