How is domain modeling evolving these days?

I talk about the progress I've made on my book and why I'm throwing it away and starting over.

Transcript

[00:00:00] Eric Normand: How is domain modeling evolving these days?

[00:00:06] Hello, my name is Eric Normand and this is my podcast. Welcome.

[00:00:15] So as you may know, I've been writing a book. I often talk about the ideas that I'm working on in this podcast, so you're probably aware the book is about domain modeling. And I was invited to speak at a meetup. Shout out to the Houston Functional User Group. Great bunch of folks down there in Houston. I was a bit jealous cuz people were wearing t-shirts and it was subzero up here in Wisconsin. It's on my website in the speaking section.

[00:01:04] I gave the talk and well, it made me wanna rethink everything. You know, once you present it and put it in front of people, I'm just not getting at the core that I wanted to touch. I'm not conveying the ideas in the right way. People get distracted by the words I'm using and how I presented it.

[00:01:34] So I started rethinking everything. In that presentation, I was trying to juxtapose software design and domain modeling, like software design has failed, very strong language. But the idea was, people have been talking about software design for at least 20 years, probably 30 years. And it's about all these rules, about how you should keep your code clean and rename stuff properly, and keep your methods small, things like that.

[00:02:17] And the reason it's failed is because it's so focused on the code. It treats the code like it is divorced from reality. You know, you just take the code and you move lines of it around you move 'em into new methods , but what about what the code is doing? What about the stuff that it, it's trying to take actions about and make decisions about?

[00:02:53] Doesn't that have any relation to how the code should look? This is a problem, right? I haven't changed my mind on that. This would be a useful exercise for me cuz I haven't done it thoroughly, but like, go through the gang of four design patterns and just look at the problem statements. What problem is this design pattern trying to solve? And the ones I've looked at, they say stuff like this design pattern solves the problem of having too many classes, and this design pattern solves the problem that your classes are too large, and this one solves the problem that you got too many arguments in a function and okay, that's great, but what about the real world that you're trying to represent? There's some process in the world that you're tracking or there's something going on that has to do with the real world, and you've just totally divorced the code from the design. There's a real problem you're trying to solve and you have to take that into account. All right, I'm gonna stop ranting about that now.

[00:04:13] I totally still believe that , but the way I presented it, people got hung up on a couple things. One is, they got hung up on the idea , what do you mean software design is a failure? My answer is that, well, you can try to do all this stuff, but the reason we are still feel like we're not doing enough, no matter how much we do, is that there's something missing from it. Go back and ground your decisions and the reality of the problem you're trying to solve.

[00:04:56] And then the other thing people got hung up on was I was talking about the real world, and to me it was a very clear idea, but to them, they had a very narrow view of what that meant. So I'll give an example. I'll give the example I gave in the talk and the view that they had of that.

[00:05:22] So I was talking about a coffee shop. And I was talking about the problem of taking an order, and the cashier is like typing it into their POS , touching buttons. And I was talking about what do we do if you try to remove soy milk from a coffee that doesn't have soy milk?

[00:05:53] And I said, well, what we should do is just consider that a noop. if it the ingredient doesn't exist, then the operation of removing that ingredient just does nothing, right? And the objection was, but wait, in the real world, a coffee, first of all, you, once you add soy milk, you can't really remove it. It's mixed in now. And it's meaningless to say, remove soy milk from a coffee that doesn't have soy milk. So shouldn't it be an error because it doesn't mean anything.

[00:06:36] What they were saying, when they elaborated a little more on the question was that the real world is the coffee and how the physics of liquids mixing together doesn't allow for removal. And then this other problem of removing something that doesn't exist. That's like a meaningless question, meaningless operation.

[00:07:05] That's the narrow view I'm talking about of the real world. I thought the real world opens up doesn't narrow it down. It opens up your idea, your perspective. But that was naive of me, and I can see how, because of the way I was speaking about the real world, I did sometimes talk about the coffee and how you can have multiple additions to the coffee, like soy milk and almond flavor and all that stuff, and I had to go back and say, well, when I'm saying reality, I'm like saying the reality of taking an order.

[00:07:56] So I laid it out. The person walks in, they look at the menu, they decide what they want. They, so they have this concept in their head of what they want to order. They verbalize it, speak to the cashier. The cashier hears it in their ear. It forms a new idea in their head of what this person wants.

[00:08:23] Hopefully it's the same idea, right? There is a chance that they get it wrong, that you speak it wrong or that you hear it wrong something, but they form an idea. Then they have to type that idea, translate that idea into a series of taps on a touch screen , then that is gonna form a new idea, I'm putting that in air quotes, an idea inside the computer. It's a data representation, some representation in memory of what that person wants. Again, hopefully it is the right idea, right? It's the same thing that the person wants, and then the POS is gonna maybe print out a ticket. So there's another translation into language or some representation on paper that's very different from the representation in memory. You print it out by where they're making the coffee, and then a person will read that again. They're gonna interpret that into an idea of what the person wants into their head. And then they're gonna take that and translate it into a series of gestures and movements in the coffee shop behind the bar to make the coffee.

[00:09:52] So there's this series of translations, back and forth, back and forth, and the POS has to be one of those stages of decoding. Decoding the button presses and then representing it in memory, probably stored to a database as well. You know, there's all that stuff. We're, we're not gonna complicate it too much with that, but then re-encode it into something that's printable for the barista to read.

[00:10:27] That's the reality. What it got me thinking was this whole confusion was that is what we need to start talking about. Reality.

[00:10:46] My book has to be partly at least about that. I can't take that for granted.

[00:10:55] The discussion went on and there were a lot of good points and what I came to realize was that domain modeling is actually not in conflict with software design, but if you define software design in the right way, it's actually a subset. It's a type of software design.

[00:11:21] Let me define software design. When you're writing software, there are many, many decisions you have to make. These decisions might be very trivial. Decisions like whether to use a for loop or a while loop. How do you name a function? How do you break something down into the functions? How do you architect the whole thing? All of these decisions are design decisions.

[00:11:59] Because design isn't just how the code is structured, it's also how it works, what it does, how it solves the problem. That's software design. It's basically indistinguishable from programming itself. It just has a richer perspective. Richer perspective that there are decisions that we have to make along the way that might not matter for whether it gets the job done, but that we know we have to make anyway. So for loop while loop, both of them could get the job done, but you have to make that decision. Maybe you're gonna even use Recursion instead.

[00:12:46] So how do you choose? Well, you have to have some goal in mind to help direct you. So that goal might be, I want it to be super maintainable. I want it to be very clear or concise or whatever. You could make it up. You could just say, I don't want to ever use the letter E. Right? So you can't use the while. These are design goals. You choose the design goals, they're up to you.

[00:13:19] Software design is making design decisions in service of a design goal or a set of design goals. You gotta deal with conflicts between the goals. There's always trade offs, but that's how I'm gonna define software design.

[00:13:45] Domain modeling is a type of software design that pursues the design goals by making one major choice, which is to implement the problem domain separate from the solution to the problem

[00:14:13] I'll give an example. Let's say my problem is I need to figure out where a cannon ball is going to land given its angle and its initial velocity, right? You can figure out, given earth's gravity, where it's gonna land. So you could like get out a piece of paper and do some algebra, take the formulas and plug in the numbers, and make a function that takes the X and Y velocities and just does the multiplication and additions and returns the X and Y coordinate where it's gonna land, right? You could do that, but that's not the domain modeling approach.

[00:15:05] The domain modeling approach is to say, let's implement a little library to represent these kinds of kinematic problems. Okay? So it might be a little bit more general than solving that one particular problem. And then you're going to write another couple of lines of code that use that library to define the problem. And to get the answer, you're gonna run that program and you know it'll tell you the X and Y coordinates.

[00:15:47] That little change makes the difference. That's what makes it domain modeling. Your domain model gives you a bunch of primitives that you can use to express your problem at a higher level, higher layer, and that expression of the problem when you run it, it gives you your solution.

[00:16:13] I've talked about this before. I'm calling it. Executable specifications. Now, this definition kind of brings up three big ideas that we need to talk about in the book. I'll just mention them here cuz this is already getting kind of long.

[00:16:41] The first one is stratified design. You gotta be able to think in terms of implementing one layer in terms of a lower layer.

[00:16:56] The next one is encoding your domain. What is your domain? What is a domain? How do you look at reality and figure out what you need to encode?

[00:17:12] And finally, there's the encoding itself. How do you encode it? How do you model the stuff you wanna model from reality?

[00:17:27] I wanna talk about how I'm restructuring the book.

[00:17:33] Before I was looking at it like there were different levels. You're gonna start and you're just learning about data modeling, and then you're going to get into operations and modeling those, using the function signatures, and then you're gonna get into, an algebraic mindset and start looking at the composition of those operations.

[00:18:02] That stuff is still gonna be in there, but it doesn't leave a lot of room for the other stuff I want to talk about. So as a structure, it's not what I need.

[00:18:15] Another thing I learned from this talk was I don't want to make a process. And design is so hard and intuitive and usually experience based, and it, it requires taste and different people are gonna disagree, but what I want to just make more available to people, more accessible to people is the idea that there's a ton of information out there that you're just not using. It's there. You're just not looking for it and you don't see it. And that information can help you make better design decisions.

[00:19:12] And what I wanna do is organize the material in terms of different ways of looking at your problem to get more information out of the data you have, so you can make better design decisions.

[00:19:31] There's no rules of thumb. I don't want design to be a bunch of rules of thumb that have a million exceptions to them. I want it to be something richer. The information is there, you're just not looking, and so I'm organizing it around what I'm calling lenses.

[00:19:56] There are different ways of approaching your problem to extract more information so that you can make better decisions, and I'll talk about that in a upcoming episode.

[00:20:11] My name is Eric Normand. This has been another episode of my podcast. Thank you for listening, and as always, rock on!