Modeling Value Objects

[00:00:00]
>> Mike North: Well, let's take a step back now and think about how we want to model this. Like right now if we look at location, it's sort of boring. Like it has a name, a region, which could be like a province or a state in the US and it has a country.

[00:00:15]
But there's nothing here that deals with this concept of like answering the question we're trying to answer. Like when can I put my plants outside? When is it going to be 50 degrees or greater? So let's think about how we would want to model this. Does anyone have any ideas?

[00:00:33]
If we were to start with location and this has things on it like name, what do we call it? Region. Oops, sorry. We've got name, we've got region. It's not gonna let me do multiple bonded space things. But like what are the other things that probably need to be part of this story?

[00:01:05]
How would you all think about this? Well, a temperature doesn't exist yet, so we need something like a temperature. What should a temperature have on it?
>> Nikita: Unit.
>> Mona: Max.
>> Nikita: Unit.
>> Mike North: Unit?
>> Nikita: Yeah.
>> Mike North: What kinds of things should I have for unit?
>> Nikita: Celsius and finite.

[00:01:30]
>> Mike North: Yeah, you're looking at like the API contract there, which is good. There's some existing software. Like unless you're starting greenfield and building something entirely new that touches no other systems. Sometimes you can look for clues in terms of what already exists, then I heard-
>> Nikita: Value.
>> Mike North: Value, that's a number.

[00:01:53]
Great, so we have that, let's pretend I'm the gardener. I've asked for this. I want something that makes this work. I want this tool to work. And I hired a designer that made this for me.
>> Mona: That Interaction between the date and the temperature.
>> Mike North: The date and the temperature.

[00:02:17]
Say Mona, you're onto something.
>> Mona: I'm not sure. I mean a min and a max would be the start of it.
>> Mike North: Absolutely. A min and a max. So what should we call this thing?
>> Nikita: Limit.
>> Mike North: A limit, we could call it that. Is that the thing with the min and the max or is it?

[00:02:36]
Range.
>> Mona: Range, range has min and max.
>> Mike North: Sort of the upper and the lower limit. So great, why don't we call this a temperature range and we could say I heard min and max. Okay, and so clearly we've got something here, we've got mine and max. So we'll represent those with two arrows and it's not quite like a belongs to because remember this here is probably,
>> Mike North: It's probably a value object like temperature because I don't think we're gonna store 56.3 degrees Fahrenheit in our database somewhere.

[00:03:28]
It's probably just sort of something that gets embedded on something stored in a database. I'm gonna make a nice little tag here. This we're gonna say is a value object and make this a different color. All right, what about temperature range? Is that a value object or is it an entity?

[00:03:56]
And I'm gonna check chat here. Range and location. Great. Yes, Santiago, you're on the right track. Entities are in the database and values are embedded on things in the database. Temperature range. Is this something that will have an id? How would we articulate this in spoken language?
>> Mona: It would always be associated with an entity.

[00:04:22]
>> Mike North: I think so, right? This is sort of like a weather report range. Like the low is. The low today is 58, and the high apparently is 82 in Minneapolis today. So this is probably also a value object, it has to be embedded on something, and, so can we just do this?

[00:04:46]
Can we say a location has a temperature range, like Minneapolis has this low and this high. Does that get us all the way to being able to estimate a date? Pardon?
>> Nikita: Some measure of time like season or month?
>> Mike North: We need some measure of time, right? We need to know at this point, here's the expected min and max.

[00:05:10]
And at another point, here's the expected min and max. That would almost let us think of this as a curve, right? Where we're trying to find. If you think of the temperature curve throughout the year, let's say, and we want to have a threshold where it's above 50 degrees starting on this date.

[00:05:26]
Where does my line intersect with the temperature curve? Well, we need some measurement of time. Let's call this a monthly temperature. Then this will refer. Let's just say this is like a month and a range. This is going to end up being an entity.
>> Mike North: Right, this will store in a database, you could imagine us reading from some data source.

[00:06:12]
We have our locations, we get our temperature data, and then at runtime we're trying to figure out. All right, you've asked for this 50 degree temperature, where exactly does that fit? Really? It's going to be something like this. Let me rearrange these slightly. This is a nice quick and dirty tool here, but sometimes the arrows get a little bit weird.

[00:06:41]
Okay, so monthly temp has a temperature range, which sort of. You can think of it as embedding a temperature range, and that embeds two temperatures. What's the relationship between location and monthly temperature? It seems like there's a relationship here. Is it one to one?
>> Nikita: Has many.
>> Mike North: Has many, has many.

[00:07:08]
We can represent that. Let's say it's one or many. Really, we're in trouble if we have less than 12 months of data here. A location which is an entity has many monthly temperatures, each of which embeds a temperature range, each of which embeds two temperatures.
>> Nikita: You're not going to store two temperatures.

[00:07:34]
You're going to store like Kelvin, for example, and then derive Celsius and Fahrenheit from that for display.
>> Mike North: That's, that's a very good, very good point there. Like, we have multiple ways we could represent this data and this. You're getting into what's called normalization, right? Let's say we got this temperature data from different sources.

[00:07:54]
Some of them are Fahrenheit, some of them are Celsius, some of them are Kelvin, which maybe, do you think Kelvin is what a vegetable gardener is probably thinking in terms of.
>> Nikita: You don't have negative numbers with Kelvin, right?
>> Mike North: Right, right, that's where absolute zero is the lowest possible temperature.

[00:08:12]
That's zero Kelvin. You don't see the kind of thing on a weather report, but it's totally a valid way to represent temperature. So we have to decide how are we storing this information and then how are we representing it in the ui. Ultimately, I see I get a little like, Fahrenheit, Celsius, thing here.

[00:08:33]
And presumably that's gonna define, I noticed when I hit this, look at the little label here, it's changing. So at the very least, this is how I'm describing my input. Presumably I want to see my output in, in the temperature I asked for, like in the units I asked for.

[00:08:51]
So that is certainly something to consider. But, like, where it would matter most is if you wanted to have charts or something that showed that temperature curve. If you're storing data sometimes in Fahrenheit, sometimes in Celsius, sometimes in Kelvin, you're creating a lot of work for like anything that is built on top of this.

[00:09:08]
They will have to perform this, like, normalization task. Right, they'll have to translate it into something that's very consistent across all of the locations, irrespective of what the data source was. Okay, let's jump in. I buy that this, as your resident gardener, I would say this makes sense.

[00:09:31]
I'm looking for a day I don't need, hour by hour, minute by minute, when the temperature is going to be what it is. Especially if I'm in January trying to figure out when do I start my plants, like there's no way like last year's day by day temperature ranges are not going to be accurate.

[00:09:50]
I want the monthly averages. That seems fine, right, it's a prediction with some error bars around it at best.
>> Nikita: I'm not really following. What makes monthly temp different than temperature range, thus that we want to make it an entity versus a value.
>> Mike North: Right. We totally could do that.

[00:10:11]
We could say. That's a very. That's a very good point. Here's an alternate representation. Does anyone see anything better or worse about this? I'll give you a better thing. It's one less thing to build, so by default it's better. Is there a downside? How would you talk to your user and understand whether you should do what we modeled before?

[00:10:49]
Or this? How would you answer that question talking to your customer? Let's say you're the tech lead on the team and it's up to you to figure out which is the right pattern. Are there some questions you might ask.
>> Nikita: If there are other places you might use temperature range?

[00:11:07]
You're gonna reuse that type for temperature range and not to recreate a new value object for temperature range?
>> Mike North: That's absolutely true. Could be. At this point it comes down to how confident are you that you're going to run into that? Or is it okay to start here and tease out that abstraction in the future?

[00:11:32]
And I mean, at this point, temperature range doesn't really add a lot of value here.
>> Nikita: Yeah, my question was more not like consolidating those two types, but where the line between a value and an entity really lives. Because obviously I think you don't want to be storing temperatures as like individual, like columns in a database, their own IDs.

[00:11:58]
It doesn't make any sense, especially if they're afloat. But you get to a point with like temperature range, like how granular are the locations? And do you really. If each location is gonna have its own range, should that be an entity or should that be a value? Because that kind of seems like an entity should maybe be reused, but I'm not entirely sure.

[00:12:20]
>> Mike North: All great, all great points to think about. Do you think we need this here? This one to many range? Like, sorry, one to many relationship? Like, I would argue any valid solution has to have this relationship. Like locations have temperature information at a point in time. So no matter what, we need this.

[00:12:47]
I think it's kind of, at this point we're just really discussing kind of like the structure of whether there's this additional level of one more value object that represents this range. It's almost like a tuple of temperatures that represent, like, the low and the high. We could have other places where temperatures exist.

[00:13:09]
Like, I don't know, maybe the tomato seed packet has, like, minimum outdoor temperature and it's just 50 degrees. Maybe there are times where we have. We'll find either a temperature or a temperature range. Some seed packets say 50 degrees, and some say between 45 and 55. But at this point, I think this is a simple representation, as kind of as simple as we can get away with for now.

[00:13:34]
And we should bias for that, right? There's sort of the role of find two or three places before you tease out an abstraction. Otherwise you can get into attempting to model all of the details of the real world. And that's sometimes a trap. You can end up overbuilding things for that purpose.

[00:13:54]
Nikita asks, should an entity have an ID? Does it make sense for temperature ranges to have IDs? You know, I forgot about this. Entities should certainly have IDs. We need an ID. There. I was sort of taking that as a given, but we should list it out. And then in this case, monthly temperature ranges should have an id or string, whatever we choose to use.