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] Let’s talk about one of the most powerful tools in the software designer’s toolkit, which is domain modeling. So domain modeling is a method for discovering the entities of our system and describing their attributes and operations. And the reason this tool is so powerful is that it’s very flexible. We can use it for, for example, if we were building the data layer of our application, we can use it to describe our database schema. So to define which tables we need, which columns we need for those tables, you know, the types of the columns and so on. In object oriented programing. This is very useful for defining the main classes and interfaces of our system. And in frontend development, which is the more relevant to us, it helps us organize our structure and align it with the user interface.
[00:51] There are a bunch of places where we can find these entities of our system, but for frontend systems in particular, there are ways that I like to start with are the functional requirements of our system and the UI specs. If we take a look at the project spec, which you will find a link to it in the description of this video, we’ll see that here we have the list of functional requirements. These are the same ones that we saw in the previous module. And if we read through these, we’ll find that there are a lot of nouns that repeat a lot, and they have a lot of actions associated with them.
[01:25] So nouns in this list, in their description of the application or of a functional requirement, typically represent an entity and verbs represent the actions that they can take. So here we’ll see that a lot of the operations, a lot of the features of the system are related to customers, which means that customers are probably one of the core entities of our system. We also see some related to restaurants and food items, which might mean these are also very important entities of our system. And we can read through these and find which other entities we may have.
[01:58] And the other places that I like to look for entities and attributes is on the UI aspects themselves. So here we have this Figma file which as a reminder this just have screenshots from Ubereats, which is the the model application that we’re using to describe FullSnack in our fictitious application. And here we can, we can navigate through some of the main pages. These are some of the main pages of the app. And if we look at this restaurant page, for example, we’ll see that here we have a lot of different attributes that we can link to our restaurant entity.
[02:31] We determine the restaurant is one of our entities, one of the more important entities. So looking at the UI specs, we can define its attributes and operations. So we can see that restaurants have a name, that they have a logo, image of some sort, that they have some sort of banner hero image at the top. They also have some delivery fee information associated with them. They have some delivery time information and they have relationship with other entities as well. So here we see that restaurants have a bunch of categories for the food items that they have. They have a they have a collection of food items as well or menu items. And then we have some reviews that are also could also be entities by themselves.
[03:21] So how do we take note of this? The way that I like to just define my entities, each is using a very simple list. So here we have an example of how I might keep track of my entities. Just a list of the entities that I discover as I go through their figma specs or that description of my features. And for each entity I may have a list of some of some of its main attributes and operations or customers. We see that we have, we are probably going to have an ID for the customers, a name, an email an add to favorites operation, which is one of the actions that they can do. And for restaurants as well, we may have other information here.
[04:00] If we like to put together a visual representation of our domain, we can grab this list and put it in in a class diagram. We can put together a class diagram or an entity relationship diagram, and we’re going to see how we can do that in one of the following videos.
[04:10] Now, here’s a question that you may have right now. Why do all of this? Why does this matter? Can we just look at the API spec, their response over API and just define our entities and the models out of that? Well, yes, we could do that, but there are a few reasons why doing this exercise of domain modeling ahead of time, specifically at the beginning of the project, it’s hugely beneficial.
[04:34] So the first one is that it allows us to do one of the hardest things for software developers in general, which is naming things given giving these entities appropriate names. So, for example, we decided that we’re going to name one of our entities restaurants, and that means that we can use that word, the word restaurant, to refer to a lot of things that are associated with an entity. So in the code, we may have then a restaurant category, a restaurant location and a getRestaurantInfo function. And all of these things use the word restaurant. And whenever we see their names, we we know that we’re referring to this restaurant entity.
[05:15] If we don’t take the time and the effort to name the entity, then the naming will be decided that whoever is that it’s implementing that feature and different people will give different names to the same thing. So sometimes we might refer to it as restaurants, sometimes as a store and sometimes as a shop. And it will be very confusing because we won’t know if these are all the same thing. Are we all always referring to the same entity, or is there a difference between a restaurant and a shop?
[05:43] For example, remember that these entities are core to your domain, so the features of your product might change. You may add an AI chatbot and you may remove the AI chatbot and you may add a bunch of different features to the product, but the entities are probably going to survive. Even your codebase itself, you may rewrite your entire codebase using a different framework five years from now, but chances are that your application is always going to have restaurants, it’s always going to have customers and it’s always going to have shopping carts and food items. So naming these things correctly, giving them appropriate names at this point is hugely beneficial.
[06:17] The second reason is that doing this exercise allows us to align the data model to the UI. So if we don’t take the time to come up with a data model that our UI needs, chances are that we’re going to use whatever data model comes back from the server. We might mimic our data model using, you know, whatever it is, this structure of the database. So in this case we may have an API response that looks something like this to represent our restaurant entity. And here we see that a lot of the data is know deeply nested. So to access the name, I have to go down three levels and then we have some data that we need like the zone ID, maybe I don’t need this information in my UI and my relationships, like my, my categories are in a format that is not very useful for me.
[07:08] So if we model the data model after the UI, we may come out with an entity that looks something like this. These are the attributes of our entity. Now, of course there’s going to be processing, which we have to parse the data or transform this data structure into this other one. But that logic will be encapsulated. So we’ll remove a lot of that complexity that comes with having to work with these data structures that are just not modeled after the UI itself.
[07:33] And finally, another reason why it’s useful to do these domain modeling exercises is that it allows us to have interesting conversations with our teams about how do we establish responsibility among our different entities. So let’s say, for example, that we identify these add to cart operation that involves multiple entities. It involves the user who is adding the add into the cart. It involves the item itself that is being added and involves the cart entity as well. So who should be responsible for this operation?
[08:03] We might say that we don’t have enough information at this point to make this call, or we may do some discovery and we might find out that we actually have a requirement that says that users can actually have multiple shopping cart one for each restaurant they are adding items from. So now we have an additional point of information. We may decide that the item shouldn’t be responsible for that, because it shouldn’t know anything about which other shopping carts exist and the same for the cart, you shouldn’t know things about other shopping carts other than itself. So maybe you will say that is the user’s responsibility. Or maybe is the restaurant entity’s responsibility to create a shopping cart for itself.
[08:41] No matter where we decide to put this operation in. The point is that having these discussions now and changing the decision at this point is a lot cheaper than changing it after the code has already been implemented.