What is a domain model?

In this episode, I continue the exploration of the definition of domain model to serve as a base layer of understanding to write my next book.

Transcript

[00:00:00] What is a domain model? Hello. My name is Eric Normand. And this is my podcast. Welcome.

[00:00:13] So I hope you'll excuse this exploration of the term domain model.

[00:00:23] I've probably had episodes before, where I tried to answer what is a domain model? And I'm still looking for the right answer and the right way to explain it. I'm doing a lot of reading, a lot of discussions with people. And I just wanted to check in and give my current understanding of this idea of a domain model.

[00:00:56] So I'm going to start by talking about what is an [00:01:00] abstraction.

[00:01:02] We use the term abstraction a lot in software.

[00:01:08] But there is a more formal definition than the ones I've talked about before. And that is that an abstraction is a mapping from one domain to another. So it's a mapping from what's called the concrete domain to the abstract domain. So an example would be:

[00:01:32] We have some bytes, some bits in memory. That's very concrete. And we know how to map those bits to ones and zeros into numbers. And that's the abstract domain.

[00:01:52] If we do it right, we're also able to map, let's say apples-- [00:02:00] you know, the fruits-- it's a concrete domain. And we can count them. And so that's a mapping to numbers also. So we've mapped bits-- zeros and ones-- through considering them, interpreting them as zeros and ones-- into the abstract domain of numbers. And we've also mapped apples into the abstract domain of numbers.

[00:02:33] Okay. So we actually have two abstractions here.

[00:02:37] And what's interesting is one can be a model can be considered the model of the other.

[00:02:47] Okay, so maybe that's getting too far field. Maybe I shouldn't talk about that.

[00:02:53] So when we're programming-- and let's say we're just starting out on a new piece of software-- [00:03:00] there's some part of the world that we want to capture. And this it's very messy and nebulous. I would draw it with a cloud. Then you just there's, there's a lot of stuff there. There's a lot of information.

[00:03:14] A lot, most of the information is not relevant to the problem you're trying to solve. Right. So if you're trying to figure out. Um, Um, some physics problem, like where is a cannon ball gonna land if I shoot it from a certain angle? Well, you're going to neglect the time of day. You're going to ignore that.

[00:03:34] Because it shouldn't make a difference to where the Cannonball lands or what color the Canon is that shoots it, right? There's tons of information like that, that you could just say it's not important, not relevant, not relevant.

[00:03:49] And you almost don't even see it anymore because you've grown up in the world and you've learned to ignore most of the information coming into your brain. But we know it's there, if we [00:04:00] actually start examining it and looking for it.

[00:04:08] So what we need to do when we've got this domain. This thing in the real world that we want to start modeling is to map it to some smaller set of information.

[00:04:25] We're making an abstraction between this complex information rich, real world system, and some abstract, information poor-- it's just got only the information you need-- system.

[00:04:45] But that's all in our head. Right. We don't actually, you. We're just thinking about it. We don't actually have a thing built yet. And that thing in our head can get really complicated.

[00:04:59] And [00:05:00] probably too complex to actually keep the whole thing in our head-- for any problem of, of a normal size.

[00:05:11] So, what we do is we build another system that maps to the same abstract domain.

[00:05:24] So maybe we draw a diagram of the canon and the cannon ball. And the angle of the canon. And the velocity of the ball is like an arrow. Right. So we're trying to capture the important features of our domain into another system that is easier, is easier. Ah, ha contains less information than the real thing, but that can also map cleanly, precisely, to the abstract [00:06:00] domain that we want to operate in.

[00:06:03] And that's the model. The model is that diagram with it's mapping.

[00:06:14] So in our software, the, the model is the concrete representation, in terms of data structures and operations, that we are building, that also maps to the same abstract domain as our problem.

[00:06:40] Okay. Now. The thing that is important is that uh,

[00:06:46] the, the model that we build, like in the example of the diagram we built, that model does have to contain [00:07:00] enough information to reconstruct the abstract domain from it. It is the concrete domain of a different abstraction. And it has to contain everything. But it certainly contains less than the real world system contains. And then also the operations have to work in a similar way. So in some sense, we are capturing some, some structure that is in the real world in our model.

[00:07:45] The structure has to be kind of a one to one mapping. Otherwise, they wouldn't be able to both map to the same abstract domain.

[00:07:57] And that's what we're trying to do in [00:08:00] our software. So we're trying to capture the structure of the real world-- the relationships, the constraints, the how the operations work-- capture that in the in the software, so that both the real world domain and our model domain mapped to the same abstract domain. That's what we're doing.

[00:08:36] Now, I know this is very theoretical. Uh, I would, I would not talk about it like this in a book that I wrote that I was trying to teach it. I think this is way too abstract, but it does help me when I'm trying to figure out what exactly is it that we're doing here? And

[00:08:58] from previous [00:09:00] experience with my other book, having like a, uh, deeper, like-- even it's just one layer deeper-- understanding of what it is we're doing, helped me write the book and make sure that it that I wasn't using terms, uh, willy nilly. Uh, and that I was explaining everything that was important.

[00:09:30] So this is the closest I've come. I think that this is, uh, this is pretty good. I it's ready. Right. This idea of a model.

[00:09:43] Now. My book is going to talk about a certain style of model, which I'm calling runnable specifications. I'm going to talk about that in the next episode. This one is done.

[00:09:57] So, thank you so much for [00:10:00] listening, and, as always, rock on.