How is domain modeling related to Starbucks?

We discuss two phases of domain modeling, one easy and one difficult.

Transcript

What does software design have to do with building Starbucks? Hi, my name is Eric Normand. This is my podcast. I have one announcement to make before I go into this topic for today. My book, "Grokking Simplicity" is published. It is physical. It is a book with paper in it, pages.

They say it's 592 pages, if you include the front matter such as the forward and the preface, things like that, 592 pages. It's an easy read. It's all about functional programming.

I won't talk about all the reasons why you should get it. If you are into functional programming, if you are curious about functional programming, this book is for you. If you're already well-versed in functional programming, it's probably not for you.

It's very elementary. It starts from learning about pure functions, side effects, and things like that. We all know someone who has asked us about functional programming. This book is for them.

I had trouble finding a book that I could recommend to other people. That's what I built, the book that I could recommend to others. If someone's like, "Hey, what's functional programming? What's it good for?" I can give them this book. It'll feel a little self-indulgent to give them my own book, but I can say I wrote this book for you.

Book is Grokking Simplicity published by Manning. You can go to manning.com and get the book. It is already at the printer. They'll print a new book for you or grab it off the shelf and send it over. Then it will soon be on Amazon. If this book sounds good to you, please go check it out.

I'm very proud of it. It was more than two years, almost three years in the making. I think it turned out great. I was very happy to flip through and see what production the Manning production department has done with the pages that I laid out. It looks awesome. I'm very happy. Please go get your copy wherever you buy books, manning.com if you can't find it there.

That was my little plug. Now we're going to get into the real topic. When we do domain modeling, there's an easy part and the hard part. The easy part is, let's say you were asked to build the software for Starbucks. You have to come up with a data model for representing a coffee order.

Someone comes in, they want a tall, they want a small coffee with dark roast, with soy milk and hazelnut flavor, whatever they want. You need to come up with the data model to be able to input that into the computer. That is pretty straightforward. Most programmers could figure something out.

They might come up with different ways of modeling it. It is a process of choosing different possible representations or choosing one among many different possible representations. It's fairly mechanical. I would say it's about 90 percent mechanical.

You could come up with -- you yourself as one programmer could come up with dozens and dozens of different ways of representing that same coffee. You have to find one that works well and also fits other stuff. Other requirements, like the kind of database, you're going to store it in, the other stuff you might want to do with that order.

You feel around and figure out what is the best way to model that. Like I said, that's the easy part -- going from Starbucks to computer program.

What's the hard part? The hard part is inventing Starbucks' coffee. I have coffee here. Coffee is not a discrete thing. There are many, basically infinite possible coffees you could make.

Starbucks only has a finite number. It might be in the millions of different possible combinations of coffees and sizes and brews and flavors and all that stuff. It's finite. It is discrete. You have three sizes to choose from. You have milk or no milk. These are very discrete choices to make.

Someone invented those choices. Someone looked at the undifferentiated field of coffee. I don't know discretized it, figured out boundaries of where the different sizes would go and how, "OK, we're going to have three roasts of bean."

There's infinite roasts of bean. You could roast it as much as you want, as little as you want, anywhere in between. They say, light, medium, dark. Boom, there's three. They have invented this form of coffee making. A different company could make a different form, a different domain, different model of how to make coffee.

That is the hard part, is you as a software designer, as a programmer, are asked to enter this undifferentiated field. I often talk about making rocketry software. Software to help manage building rockets, something like that. This is undifferentiated. There are people doing rocketry, but they're experts. They have not broken it down into their 12 kinds of rockets.

They have not classified things into such discrete buckets. Maybe they have. I don't know anything about rocketry. Maybe that's a bad example. Another example might be a restaurant where you could mix anything together in any amounts, cook it for different ways in different amounts of time.

A chef invents a recipe and somehow has to take this refrigerator full of food, and a kitchen full of cooking equipment, and turn it into a discrete thing. That's the hard part. We walk into a domain that we are probably not that familiar with. We're not experts in it.

We have to start cutting it up, dissecting it, figuring out what are mutually exclusive options? What options can you make together? How many different sizes of coffee can you have? We have to basically build a model first before we can write software for it. I don't know. That's what I wanted to talk about.

There's a pretty mechanical, learnable set of skills that would get you to be able to take go from models developed already. We have Starbucks. Now, write software for it. That's a pretty doable thing. The hard part is that other half, which is way bigger than half, but that's how I've cut it into two.

That other part, that is something much more difficult to talk about. I wonder if there are concepts from the second part that could tell you at least what you should be looking for. The things I'm thinking of, are there any combinations? When you make a Starbucks coffee, there's different combinations of size and roast.

You're going to have a small dark roast. You're going to have a small medium roast. You're going to have a medium, light roast. You're combining these two choices together. Then each choice is an alternative. You can only choose one size of your coffee. It's got to be small, medium, or large. You can't have a small and medium, it's got to be one.

It's an alternative you have to choose among the three alternatives. Those alternatives multiply with some of the size alternatives, multiply with the roast alternatives. That gives you this combination. Maybe you should start looking for those or construct them, build, make them.

Say, "Well, we want people to have so much choice, but not too much choice. Can they really have any sized coffee? We can't really have infinite number of cups waiting. We're going to give them three choices. What should they be?" You start building this model. Discretization might be a thing, bucketing. I'm going to write these down because I just came up with them.

That pretty much nails the idea that there are two steps. The first step is very hard. It is actually taking this undifferentiated, completely continuous real-world thing, physics or stuff moving around. [laughs] Let's call it stuff happening in the world. Then turning it into Newtonian mechanics.

A concise model that describes the phenomena you see in some small subset of the phenomena you see. Then taking physics and modeling it actually is not that hard. It's already a mathematical equation. You can turn it into some variables and stuff and some functions and formulas, and you have a model of physics.

The hard part is that first step. My name is Eric Normand. This has been a little thought on software design. Buy my book, Grokking Simplicity. It's all about functional programming. I'll talk more about it in future episodes.

If you're interested in software design, in functional programming, or in my book, hearing more about it, then you should subscribe. Tell your friends about this podcast as well. I always appreciate that. I also appreciate if you make a review, a rating or a review. Thank you so much for listening and as always, rock on.