Module 3: Designing

18. Entities, Modules, and Components

Resources

Transcript

[00:03] Throughout the rest of the course, we’re going to talk about these three concepts quite a lot. So I thought I’ll record very short video to talk about what I mean by them.

[00:17] So first of all, we have entities and entities. They represent sort of the main building blocks of our domain. In the case of FullSnack, for example, in the case of the domain of the FullSnack problem, we may have a restaurant entity. We may also have a customer entity. We may also have a food item entity or a shopping cart entity. And these entities, they also have typically attributes within them. So a restaurant may have a name and they have an address, may have a logo, for example, and they have operations and relationships with other entities as well.

[00:49] Now, entities are an abstract concept. They only exist in our heads. So we may draw a diagram. We may draw a box that says that that’s our entity. But again, it shows a box in a diagram and it doesn’t exist in real life. But when we actually start implementing the application, we’re going to see how we can represent this entity into an actual concrete piece of code.

[01:13] Some of the most common ways in which we can represent entities in our system are you see that model in the case of an MVC framework, for example, we may have a model that maybe fetches some data from an API, parses the data somehow and has some some custom operations that are all related to restaurants. Another way to represent entities as code is, for example, using a class or an interface or type. In the case of TypeScript where when we have a restaurant type that has all of its attributes and operations and we may also see it represented as a service in the case of React, for example, common ways to use a custom hook that under the hood may be fetching data using React query or something like that, and maybe define some functions for the operations of restaurants.

[02:01] Then we have modules, and in the same way that modules are, the building blocks of our domain modules are the building blocks of our application. When we start breaking down the application, which we’re going to see how we’re going to do that for a FullSnack soon. The first level of breakdown is going to be modules are going to start breaking down the applications into modules first. So we may also have a restaurant module. We may also have our customer module and so on. There is sometimes a 1 to 1 relationship between our restaurant and between an entity and a module, but that’s not always the case. So this is not a hard rule that we have to follow.

[02:37] Again, this is also an abstract and abstract concept. The module itself. But concretely we might see it represented as a folder in, in our in our code base or as a route or a page, depending on the framework that we’re using.

[02:50] And finally, we have components which don’t really have an abstract representation. So we typically see them in code as a view, in a case of an MVC framework like Backbone or something like that, or a UI component. In the case of more modern component base framework like React, Svelt or View.

[03:08] So in this module, in the design phase, we’re going to focus more on the abstract concepts. So whenever we refer to entities and modules, we’re talking about the concepts and not really about the concrete implementations. So these are the ones that we’re going to see. Imagine number three and then imagine number four. When we actually talk about the implementation, we’re going to be talking about all of these concepts from from a concrete implementation standpoint. So we were actually going to see how they actually look in the code.