Is deferring decisions about our domain a good idea?

I wonder when to deal with business rules. Do they belong in the domain layer?

Transcript

[00:00:00] Is deferring decisions about our domain a good idea?

[00:00:05] Hello, my name is Eric Normand. This is my podcast. Welcome.

[00:00:11] So today I was thinking about a little issue that we have with our pizza system, we've got currently an array, an array of toppings, some kind of collection of toppings, and one of the issues that I mentioned was that collections can have any number of items including zero, and more, like a thousand toppings on your pizza. But our domain, at this restaurant, technically you can only have three at most. And so there's this problem where you can represent a pizza [00:01:00] with a thousand toppings. You can represent that, but it doesn't really work.

[00:01:06] If you ordered that somehow, if the validation was broken and you ordered a pizza with a thousand toppings, well what's gonna happen? The real question is what do we do? Do we enforce validation? And where do we put it? So my idea is this, and I'd love to hear what you think about it.

[00:01:31] My idea is that what's really important is to ask "Why are we limiting it to three toppings?" Now, if you ask someone at the business, they might have an answer like, "Oh, well we've tried with more than three, and it doesn't fit on the pizza, or the pizza dough can't handle that many toppings," or something like that, [00:02:00] right?

[00:02:01] And so the business has come up with this rule that says no more than three toppings, and that's the end of it. But where's the real divide? First of all, you can conceive of a pizza with four toppings. It's conceivable. It's not outside of the realm of imagination. You can easily understand what it means.

[00:02:28] What I wanna argue is that it's actually not part of the domain. This limit on the number of toppings. It's part of the business. The domain is making pizzas, and the business is more of this particular shop's rules for how they make pizzas.

[00:02:58] And how do you really distinguish [00:03:00] this? Well, you can imagine another pizza shop, a competitor, that uses this exact same pizza domain except they allow four. And then there's another competitor that now allows five toppings. And you can see that there could be an inflation or an arms race for the pizza shop that allows the most number of toppings.

[00:03:28] And they could all be using the same library that they got off GitHub, that represents pizzas as this JSON that we've got. So it's really a business rule. It is not a pizza rule. My recommendation is to use stratified design and to make two different layers. One layer is your pizza domain layer, and the next layer is your business [00:04:00] layer, and you enforce that topping limit in the business layer.

[00:04:08] So you defer the decision outside of the pizza domain. It simplifies everything to not have to put checks in there. You can just defer that decision to later. The business will have all sorts of other rules as well, so it'll have like a place to check those rules. It might be validation, it might be something else. So I think, yes, it is good to defer those decisions.

[00:04:41] The other thing is not only could another business use a different limit of the number of toppings, but also the same business could change their limit, and you don't want to bake in the limit into the pizza. Because everyone who works there [00:05:00] knows how to make a pizza with four toppings. Just add one more after you put three.

[00:05:06] In Grokking Simplicity, I mentioned it. If you have a domain layer and then a business layer, and people are always like, "What's the difference?"

[00:05:15] Well, this is an example of one of the differences. If your domain could be used at a different business with a different set of rules, but still be useful, then it's really part of the domain.

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