When do we want to refer to things by name?

In a domain model, when should we refer to things by name, and when should we nest a subcomponent?

Transcript

[00:00:00] When do we want to refer to things by name and when do we want to nest them inside of another entity? Hello, my name is Eric Norman and you're listening to my podcast. Welcome. I'm writing this domain modeling book, and this is one of the concepts I. It requires, requires some attention to, and I wanted to bring it up because I was thinking about how to explain this and how to write it down, and so I have some ideas about it.

[00:00:39] So here's, here's the main cru of the, the, the problem,

[00:00:48] or here's an example, let's. Put it that way. So I want to represent a pizza that I'm gonna order at a restaurant, and [00:01:00] that pizza can have toppings and the topping. Obviously the topping has a name like Olive or Artichoke Hearts, and the topping also has a price. because different toppings have different prices.

[00:01:29] So the question is, should I include a, I'm gonna have, let's say I'm gonna have an array of. Of these toppings in my pizza representation, should I include a, let's say a hash map that represents the topping and its name and its price inside of the pizza.

[00:01:58] So I would argue. , [00:02:00] you want to simply name the name, You use a string. Basically use a string that says Artichoke hearts or. Uh, or bell pepper. And so that also will work. And then how do you get the price? Well, you have a separate piece of data, like a lookup, a mapping from the name. To price, because as a consumer, as the customer, I do not get to set the price.

[00:02:42] My pizza does not own the price of that ingredient. This is simply a request that you make this pizza for me and a description of the one I want.

[00:02:58] So [00:03:00] when I explained it that way, it kind of sounds obvious that I, I just want to name the ingredient and have something else know about the price. So why should I even bring this up? Well, I'll tell you, I think that it's not so obvious, uh, especially considering the history of. Object oriented programming because when you look at how object oriented programming has been taught, a topping on a pizza would be a, has a relationship between the, the pizza and the topping.

[00:03:44] The pizza has or has many toppings, and the topping has a price. And so you would represent that relationship as [00:04:00] a reference, as a pointer, which takes you out of the realm of data and into interacting object. , right? Because that pizza is allowed, because it has a reference to it. It's allowed to call methods on it.

[00:04:25] And if you're modeling it in the sort of, I guess the mainstream object oriented way, some of those methods might be like set price, and that's just not that it.

[00:04:46] I don't mean to, to pick on object oriented programming here. I just wanna show that it's not the main, the, the mainstream object oriented programming way is not [00:05:00] the way I want to teach, and that it, it really does differ from the way I believe domain modeling should.

[00:05:15] This gets kind of more into operation modeling, but what does it actually mean to set the price of an ingredient? Does it, you know, you have to think about the semantics of that. Does it change the price for everybody because maybe that object is shared between different pizzas, or do you construct a.

[00:05:44] Topping object for each pizza. You know, these are questions that are usually left up to the programmer to figure out. They're not really part of the [00:06:00] uh, uhl diagram. when you're building these kinds of things. And I think that they're super important. They're, they're the key to making your program successful and they're left out.

[00:06:16] And I think this question of just giving something a name is frowned upon in the object toted world.

[00:06:29] Okay? So I believe that in this case, You would just wanna name it because the pizza does not own the concept of artichoke hearts your business does, right? Like artichoke hearts was gonna have a price. Maybe there's another look up for like, where do you keep it or how many you have in your inventory.

[00:06:55] Like these are all different ideas about artichoke [00:07:00] hearts that are not owned. By the pizza, Certainly not from the perspective of a customer, but when would you wanna nest? Well, in some cases, most cases, or many cases, you would have a nesting when the thing is owned, when it can change within the context of that one.

[00:07:33] So, uh, one example I've been working on in the book is if you have different kinds of sauces and you have, let's, let me list, let me have a tomato sauce. You have a pesto, like a basal pesto, and you have a beel sauce. If you're making a white pizza, well, that tomato sauce can have a spice. [00:08:00] Okay, so it's not just the name tomato sauce.

[00:08:05] You want to ha it has this sub state of spice level and we'll just do mild, medium, and hot just to, just to make it simple. Now, that would, you would need to nest inside of the sauce, right? But that of course does have. a uh, an ownership idea that the pizza does own that particular sauce. With its spice level, it's not, If I change the spice level on the tomato sauce, it's not the same sauce that another pizza has.

[00:08:51] In contrast, if I change the price of an artichoke hearts on this pizza, , Why? Why should I be able to do that [00:09:00] when, And then do other, Does it change the price of other pizzas? Like it doesn't really seem to to work, Right. Usually the business would set the price for the pizza, whereas the customer is setting the spice level.

[00:09:23] Okay, So there's. They're, they both work. It's just that the naming of a sub component instead of nesting the sub component,

[00:09:43] uh, seems to have some rules about when you would use one and when you'd use the. All right. That's all I wanted to talk about. I'm, I'm gonna go into it in the book of like, when you would choose one over the other. These are the kinds of, [00:10:00] these are the kinds of discussions that I think are important to have at the data model level that we just don't have.

[00:10:09] And well, now I'm gonna rant a little bit about the state of the industry. I feel like these are the real, the real. Skills that people need that just never get talked about. These little basic skills,

[00:10:29] just how to do basic data modeling. All right. This has been a, a shortish episode, but a useful one for me. Hope it was useful for to you. Uh, I'm very open to your ideas. About how to make this more clear, uh, whether you think it's important, whether I'm missing something, let me know. Uh, I'm writing this up now.

[00:10:57] I do plan on [00:11:00] self-publishing the book and publishing it in public, meaning as chapters come out, they'll go onto my, my website and so you'll be able to read them and comment on them. Man, I'm hoping that that gives a lot of valuable feedback, uh, and that would be so awesome to make this a really useful book for other people.

[00:11:24] So, uh, please, if you come across it, go or, or you want to help, just, uh, send me comments because this, this is how we can make it better. All right. My name is Eric Norman. This has been, Another episode of my podcast. Thank you for listening and as always, rock on.