-->
Subscribe to access the entire course.
🌶️ tip: unsubscribe at any time.
Ah, that's a great question!
Frontend at Scale is a bi-weekly newsletter (as in, once every two weeks) that is all about software design and architecture for frontend engineers.
Subscribing to the newsletter is the best way to support my work and encourage me to keep making free resources like this one.
I probably don't need to say this, but I would never ever spam you—and you can unsubscribe with a single click at any time.
Already subscribed? Don't worry, you won't get double-subscribed. Nobody deserves to read my terrible jokes twice.
Module 3: Designing
[00:03] Here is my version of the solution for this exercise, and I simply updated the list. I completed the list of entities with some of the entities that I found, like menu items and categories and options for the menu items in the shopping cart. And then I added some of the main attributes and operations for each one of those entities.
[00:24] And at the bottom you see that I have the class diagram that I mentioned, which I build by simply copying this list and giving the list to chatGPT and asking it to give me a class diagram in mermaid syntax. This type of diagram can be useful when we write in our design document, for example, or when we were trying to explain how some feature works. And then we can see that all of the entities that are related to that particular feature, we’re talking more about class diagrams and design docs later in the module.
[00:53] Now, I wanted to call out a couple of things that I found interesting while doing this exercise. The first one is that for some data types I had to make a best guess about which data type to use, like this delivery time. I decided to use a tuple of two numbers. This might not be the final data type, but it will be at least a discussion point with my with the rest of the team to figure out how do we want to handle these data on the UI layer and on the data layer as well. What the difference is going to be, how we’re going to parse the data and so on.
[01:24] And the other thing that I found interesting is that I had to name some some of my entities while naming some of my entities, I found that I had two different types of categories. We have a restaurant category which represents the sort of the type of restaurant that it is, whether it’s our fast food restaurant, Japanese restaurant, a mexican restaurant, and the categories of menu items. So these could be breakfast items, dessert feature items, burgers, pizzas and so on.
[01:54] Now, I originally name this one the restaurant category, simply category, because he was the only one that I had. But when then when I stumbled upon these other one, this other type of category, I renamed these one to be more specific. And that that will help because in the future, if we find the name category just in the code and we we know that we have different types of categories among our entities, then it won’t be really clear which type of category we are referring to, especially because both of these categories are related somehow to a restaurant. One is the category of the restaurant itself. Which type of restaurant is. Another is the categories of the menu items of that restaurant.
[02:33] So this is one instance in which naming naming things ahead of time can be beneficial in some cases because changing the name of this entity, it only took me a couple seconds at this stage. But of course, if this had been implemented already, renaming all of those files and functions and types and classes that I may have using just a simple name category might be a lot more work.
[02:56] So that’s it for this exercise. I hope you gave this one to try. And I’ll see you in the next video.