What is a domain model and how do we think about them?

This is an episode of Thoughts on Functional Programming, a podcast by Eric Normand.

Subscribe: RSSApple PodcastsGoogle PlayOvercast

In this episode, I talk about the three-part model of domain modeling and what it means about how they are used.

Transcript

[00:00:00] What exactly is a domain model and how do we think about them in my new book? Hi, my name is Eric Normand, and this is my podcast. Welcome.

[00:00:15] Today I want to talk about how my idea of domain modeling, where it's at now, it's been evolving. I've been, I've given talks on it. I've talked about it here on the podcast, and each time it's a little bit different, but it's converging on something that I feel is quite useful.

[00:00:39] And I don't even know if I'm gonna go through this that much in the book. It'll certainly, it'll certainly be there, but I'm. Spend a chapter explaining what a domain model is, um, in this, in these terms. But anyway, here's, here's what I've come up with [00:01:00] by piecing together, uh, what people have written and, uh, researching the ideas of abstraction and stuff like that.

[00:01:11] So a domain model is, It actually has three pieces. You gotta visualize this as a diagram, so you have the domain, which is the real world situation, the thing that you are trying to get done and model. And that's in, that's one piece. Now, when you, when a person looks at that piece, they see they, they have an a certain abstraction, meaning they're going to ignore some things and, uh, highlight and focus on other things in that domain.

[00:01:54] And so they're gonna get an idea of the situation [00:02:00] of the state, of the situation. And that idea is the conceptual model. Okay? So they, they, a person will look at the world, they get this conceptual model of the situation, and then they wanna write it. So how do they write that down? In what way? They're gonna have to encode the stuff from their conceptual model into some written form.

[00:02:34] And that written form is the domain model. Okay. So the, the interesting thing is that the way you map from conceptual to domain, so. What's in your head to your written form is in a way that you can reconstruct the conceptual model [00:03:00] later when you read it. Okay, So there's these three parts and they all mapped the The two.

[00:03:07] The two, the, the domain model and the domain both map to the conceptual model. There's an arrow. From each pointing up to the conceptual model, because the conceptual model is like purely abstract. Some, there's some, you know, ba essentially we're gonna just treat it as magic. There's some magic happening in your mind that allows you to, you know, imagine, to conceptualize the situation.

[00:03:40] And you need to be able to map both the real world and this encoded. Back into your mind. Now we can imagine a situation as an example to, to illustrate this and how a computer program [00:04:00] can fit into this. All right, so imagine your. Ordering a pizza, first thing you gotta do is you read the menu. So the menu is an encoding of the conceptual model of the kinds of pizzas that you can order the, So that's the domain, the kinds of pizzas you can order.

[00:04:22] That's the domain. The menu is a domain model, it's an encoding. And when you read the. You have a conceptual model of the kinds of pizzas that will eventually get created, okay? There are gonna be certain sizes, certain kinds of sauce, certain toppings on them, right? And, and that's all encoded in the menu.

[00:04:47] If it's a good encoding. It's going to be very clear when you read it, the what the conceptual model is, and everyone's gonna share a conceptual model when they see that menu. [00:05:00] An unclear encoding. Of course, different people would have different ideas. Maybe you need to ask questions, and there's a lot of confusion, so people will be ordering the wrong pizzas or pizzas they thought they would like and they don't.

[00:05:16] There's a, there's an idea of clarity of encoding there that is important. Okay, So you read the menu, you are basically mapping from encoding from the domain model into your conceptual model. Then you're gonna tell the waiter your order. So you're now re encoding your order from your mind into words.

[00:05:48] You're speaking them to the, to the waiter, and the waiter is taking those words and decoding them back into a conceptual model for themselves.[00:06:00] Okay? Then, Hmm. The waiter has the conceptual model and is going to write it down for the cook. Okay? So this is another encoding in a different form, in a written form, maybe even in an abbreviated form, cuz the cook knows a lot more context.

[00:06:22] And boom, now it's on a piece of paper. The cook is gonna read it, it goes back into a decoding stage, back into conceptual. Now the cook has an idea of the pizza you want, and then finally the cook uses that conceptual model, that idea, and then makes the pizza. Okay. There's a lot of stuff going on, like they're gonna map that.

[00:06:53] The pizza. You want to muscle movements and a plan for. [00:07:00] And how to assemble the pizza and where to go get the ingredients that they need and all that stuff. We're gonna, we're gonna make it simpler and just say they're gonna make the pizza. They're gonna kind of encode that back, but into the real actual domain of pizza and not into, you know, an encoding of a conceptual model, but that the pizza can also represent itself.

[00:07:25] Right. It's kind of self-evident cuz the toppings are on it. You can see the size and all that. So there's, there's some fudging here where the real domain can also be its own encoding its own model.

[00:07:43] All right, so we, we had this decoding and end coding and decoding and end coding several times before we got to a. What a computer program can do is [00:08:00] be one of those, or more than one, uh, decoders and end coders. Right? You can have a parser that can read. Some kind of, let's say it's in a, a data structure, a JSON, you know, print.

[00:08:20] You could print JSON onto paper and then this computer can read the JSON, uh, construct an in memory quote, conceptual model of the pizza, and then re-encode it into some other form, right? Or maybe can operate on it in some other. Instead of sending it to the cook to be cooked, uh, they can, the computer can say, send it to the accounting department so they can keep track of how many types of ingredients they need, how, um, like what their inventory needs to be.

[00:08:58] Or marketing can know, [00:09:00] hey, this super popular, right, so they can send it this, this encoding can be sent to different departments and decode it again. decisions from, Okay, so that's the idea of domain modeling is that your software is participating in this information flow that goes from, that goes from encoding to conceptual model, back to encoding, back to conceptual model That's just inherent in all types of information.

[00:09:35] And domain modeling is kind of the art. It's an art of constructing the encodings so that the conceptual model can be, can be maintained with a high fidelity. Okay. It's also about deciding in certain. [00:10:00] No one has really thought about it before. What needs to be written down? What is actually important to be able to reconstruct right there?

[00:10:12] There's usually, people have all this tacit knowledge of a, of a business, of a, some situation. There's so much context that they're holding in their head that they never think to write it down. That's how humans work is. We just work with a very high context. Computers aren't so good at that, and often one of the things that the computers let you do is to, uh, operate in situations with less context because you en you can encode more in the data cuz they're very fast at reading data.

[00:10:49] And so instead of high contact human communication where only a few words need to be changed. You can exchange megabytes of data that [00:11:00] a human would never be able to, to, you know, take them an hour to say, And this way you, you can have a richer information flow. And the context is all included in that information flow.

[00:11:16] That's, that's maybe getting too far, uh, into like theory and I, I wanna stay in the realm of practice. when we've got this, uh, this, this, this model of, you know, the domain, the conceptual model, and the encoding, which I'm calling the, the domain model. All this is the, this is the heart of the book is. Do we do this?

[00:11:54] And you can see because there's two arrows, there's actually two steps that have to [00:12:00] be done. Both have to be done well, or you know, both can be done poorly or well. And we'd rather do them well. One is the, I call it the easy one. If you have a really well defined conceptual model, you just have to find an encoding.

[00:12:21] That will have a high fidelity, high fidelity, uh, decoding, right? It's gonna contain all the information to represent all the possible states in the conceptual model, right? The con, the conceptual model's gonna have a certain number of possible states that it's in. So again, talking about pizzas, the pizza, a, a particular pizza can be.

[00:12:50] A number of states, depending on how many toppings are possible and how many different sizes, et cetera, and we went over that with a product in some types, right? [00:13:00] Th this is just straight up encoding the the possible states from the conceptual model into a structured form.

[00:13:18] You know, it could be JSON, it could be, uh, has school types. It could be Java classes. You know, I'm not, I'm very agnostic there. That you could just encode this somehow into a structure that can be read in and uh, operated on inside your inside memory of your computer. But then there's this other side, this other arrow that goes from the domain to the conceptual model.

[00:13:48] How do you even. Look at a situation, the complex world, with all its, it's stuff, all [00:14:00] the stuff that needs to be ignored. How do you know what needs to be ignored? How do you know what you can get away with? What needs to be in there? Sometimes we look at a situation and we say, Oh yeah, there's two possible states, but really they're seven or eight.

[00:14:15] And we'd some. Like ignored it because we're not, uh, we're not, we don't have the precision yet to see the resol at the resolution we need because we're not that experienced with the domain. And this is the hard part. This is the, the, the part that requires really thinking analytically, scientif. What needs to be in the conceptual model?

[00:14:49] This is the part that I'm having the most trouble with teaching because it's, it's just kind of an art and I, I want to help [00:15:00] people see that, that this is possible, that you can break stuff down and you can, uh, do. Do it analytically and learn it. It's a skill that you can learn. So I'm trying to break down this skill to different stuff.

[00:15:19] One thing that really helps is to do the full path from domain to encoding. What do I mean by that? Uh, by writing it down in a programming language or a data format language.

[00:15:38] You actually can start to see it better than if you just kind of keep it in your head. This is one of the aspects of Runable specifications that I like by writing down a type or, you know, let's say a has type for a [00:16:00] particular situation because it's so formal. It forces you to make choices, and you can see immediately if those choices are right or wrong.

[00:16:12] You can see immediately, Oh, this is a product type and a some type, But then, oh, what about this situation? It, there's, there's not represe presentable in this encoding. I have to change my encoding. So the idea I suppose, is to get it from. From real world situation through conceptual model, all the way to encoding as quickly as possible because once it's in encoding, you can, you can see it a lot more clearly.

[00:16:47] It's easier to communicate with your team about it so you can collaborate. The errors in it become evident very quickly.

[00:16:58] And this [00:17:00] is, this is perhaps controversial in the modeling world. A lot of people like to use UML, something that is meant to be less formal than a programming language. And I find when I use uml, the first thing I want to do after I like draw the diagrams is go and like try to encode it because there's information that's not captured in the encoding, and I know that it's probably what they are probably saying is like, maybe it's too early, we need a more sketchier version.

[00:17:43] Of this before we choose an encoding,

[00:17:47] which I can understand. You wanna, you want to, uh, you know, thick pen lines, thick marker lines before you draw the fine, uh, the fine [00:18:00] version with very thin lines. I get that. You don't want to pull out the ruler before you even know whether you're drawing the right thing at. It makes sense, but I just find that I, I, as soon as I write the sketch, I wanna see what it looks like in j s O because then I can see the relationships between things at a much higher resolution.

[00:18:26] So that's my idea. Uh, the, the uml. It is good for coming up with these conceptual models, but it doesn't give you the resolution You want to understand whether you're, you're capturing everything.

[00:18:45] All right. Um, that is all I have to say about that. It's a model of models, which I, I, I really had to struggle to not say , not talk about the [00:19:00] model of models, but we do. This three, I'm just gonna summarize three pieces with arrows between them. Now notice, okay, this is an interesting thing about it. I'll talk about, you have the, the domain.

[00:19:16] So the real world situation, which is in a certain state relative to a conceptual model, that conceptual model needs to, You need to be able to map the real situation to this conceptual model. It's simpler than the real world situation. Much, much simpler. And then you need to find an encoding such that you can decode it back to the same conceptual model later.

[00:19:46] So there are arrows going in both directions, right? There's, when you're making a pizza, you have a conceptual model of what the pizza will be. [00:20:00] What the person has ordered, that's in your mind. And you need to be able to map that back down into a pizza, right? So there, that's an arrow going from conceptual model to real world situation.

[00:20:13] But when you see the pizza, you can read it and so it's, and know what kind of pizza it is. So that is going back up to conceptual model, right? So there's arrows in both directions, like. When you write down a pizza, you're going from idea to cons, to to encoding, and then when you decode, when you read it back in, you're going from encoding to decoding to conceptual model.

[00:20:44] So there's arrows both there. Now what I wanna, what I wanna ask is, what is the relationship between. The pizza that I wrote down in my encoding [00:21:00] and the pizza that I, that I have, you know, a real pizza that is the same, you know, that has the same conceptual model. There's no direct relationship. Everything goes through an arrow to a conceptual model and then back down to an encoding.

[00:21:21] Everything goes up and.

[00:21:24] nothing goes just straight horizontal. So, So what is the relationship? And the relationship is actually quite interesting. It's that they all map to the same conceptual model. That's the only thing that's in common. You know, if you go from paper with a, you know, an order written down on it, pizza order. It maps up to a conceptual model and then it maps back down to a pizza.

[00:21:57] The only thing in common that they're [00:22:00] both, that, that goes through is that it's the same conceptual model,

[00:22:04] so we just need to make sure that those arrows don't, we don't, we don't want to play a game of telephone with those. Us we need to ensure that the encoding and decoding is, uh, is very faithful to that conceptual model or, or to whatever is the most important. And I guess the most important is the actual pizza in a, in a pizza business.

[00:22:32] Did we make the pizza they wanted? Right? Are they happy with the pizza they got? And so you fix that one as like, this is. The most relevant and important one, and then you have to make sure that all the encodings and decoded. Get you to that pizza. All the little steps going through the waiter to the cook, all that [00:23:00] from the, you know, even the menu, the, the customer reading the menu, all that has to go right to the same pizza, even though it's gonna be translated.

[00:23:09] Several times. Okay. So that's a very important property of these, of these domain models is I'll, I'll say it briefly here. It's probably worth another episode.

[00:23:26] Does your conceptual model represent this, the important concepts in your domain? Right. That's, there's a, a notion there of a fit. Like, is this a good conceptual model for how pizzas get made here? What kinds of pizzas you can order. It's possible to get a really bad one, right? A really bad conceptual. And that [00:24:00] that's a, that's what I said was the hard part is coming up with that conceptual model that really does capture it.

[00:24:06] And then two, do we have a good encoding and decoding that can reconstruct that conceptual model faithfully? And we'll talk about how we can do that, uh, in another episode. So that's it for this episode. My name is Eric Normand, and thank you for listening and as always, rock on.