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 2: Understanding
[00:03] The C4 Model is a series of diagrams that we can use to visualize the architecture of our project with different levels of detail. It was developed by Simon Brown. He is a writer, an architect, a speaker. He talks a lot about the C4 model. He teaches the C4 model. He wrote a great book on software architecture for developers. You will see it referenced at the end of the course. And yeah, he’s the best person to explain the C4 model as well. So I will link to one more resource where we can learn more about the C4 model directly from the source.
[00:40] Essentially the C4 model, you can think of this, and this is the way that Simon also likes to explain it, as a Google maps for your code. So in the same way that you can use Google Maps to zoom in and out of a particular area to see more context or more detail, you can do the same using the four levels of the C4 model, the four types of diagrams that shows our architecture with different levels of detail.
[01:04] So essentially the four levels are the context diagram, at level one. This is the one that we saw in the previous video where we saw that system context diagram for our FullSnack system. Then at level two, we zoom in to a particular system or software system, we zoom in to see its contents, and that’s the container diagram. We see all of the containers inside of that particular software system. At level three, we zoom into a particular container to see its components, and this is the component diagram. And at level four, we do the same where we zoom into a particular component to see how it’s represented as code.
[01:51] Let’s do a quick overview of each one of these four levels to see what they’re all about. Level one, we have the system context diagram, and this is the one that we saw earlier where we see the system that we’re working with, the software system as a box in the middle and we see the context around it. The context is essentially two things. We have the users of the system and the external systems like we have here.
[02:13] One thing that you will notice across all of the C4 model diagrams is that each of the boxes has not only a label describing, you know, what it is, but also a short description describing what they do. And also all the arrows, you’ll see they also have labels and this is important. The C4 is to remove the ambiguity about, you know, not knowing what something is actually doing. The idea with C4 is that you can look at a diagram and understand at a high level what’s happening.
[02:40] This type of diagram, Level one, is very good for documentation. The system context is not something that changes very often. So the chances are that your system contacts will stay, it will stay relevant and accurate for a very long time. And it’s also very good for sharing with non-technical people, any stakeholders like PMs or maybe the CEO who may not be technical, but they want to get an understanding of how things work. This type of diagram is perfect for our use case.
[03:10] At level two, we have the container diagram. This is where we grab one of our systems, we open them up and we see them represented here. So in this case we see our container, sorry, our system represented as this dotted box. Here we can see the same context around that. We see the same user and the same external systems. But now we also see the contents, which in this case are different containers.
[03:30] So in C4, containers are applications, including web applications, mobile applications, APIs, and also databases, those are the two most common types of containers that you will see in a containers diagram. And we see the same conventions where we see descriptions for our boxes and labels for arrows across all of the different containers.
[03:53] This type of diagram is also useful for documentation because this might change more often than the context, than the system contact itself, but doesn’t change that often. So this is also very good and also good for non-technical people because we’re still not talking about particular technologies here other than just maybe describing here. You’ll see that there’s a small level describing the frameworks or the stack of that particular technology. But this is just to orient people, not really to really understand what the difference between Angular and React is.
[04:27] Then at level three, we have that component level. Here we zoom into our particular container and we see its components. So components depends on which type of application we’re working with. In this case, components are referred to the main classes of the application. In this case, we have controllers, we have some spring components and we have a facade that represents sort of the main building blocks.
[04:49] For frontend applications in particular, I find the component diagram a bit, not as accurate, not as useful I’ll say, than for backend systems. So I have some small modifications that we’re going to talk about in the next module when we start designing our system. But for now, just know that this is how a C4 standard component diagram looks like.
[05:08] We follow the same conventions before, and this is more aimed towards technical people like software architects or developers. Also, you don’t want to draw one of these for all of your containers. You don’t want to write these for documentation because this gets outdated very quickly. Your code changes often, so you’ll want to keep this updated.
[05:31] And also, there’s no really good way to automate the development of this because this doesn’t represent all of your controllers, all of your classes in your application, because that would be just too overwhelming. This represents your main ones, the ones that are more important. So generating this automatically out of code is not really straightforward and in a lot of cases, not really necessary.
[05:52] You only want to do this when we’re, for example, trying to explain something or communicate a change that you like to make to the architecture. Maybe you’re putting together a design doc or a discovery doc where you’re trying to explain to the development team how things work at a high level and what are the changes you like to make. But beyond that, you don’t need to keep one of these level three diagrams for all of your containers.
[06:17] And then finally, at level four, we see the code diagrams, and these can be any type of diagram that represents how things work at a code level. This case, we have a class diagram, but it can be an entity relationship diagram, it can be a component diagram, so on. And again, we’re going to see the way that I like represented level four for frontend systems in the next module when we talk about breaking things down into modules and components.
[06:41] So that’s essentially the four levels of the C4 model in a nutshell. If you want to learn more about the C4 model, there’s no better place than C4model.com, the official website, and there’s no better person than Simon Brown to explain them. So you can go to any of the many talks on YouTube. You Google Simon Brown C4 model on YouTube and you’ll find a ton of conference talks.
[07:04] All of them are great because Simon is a fantastic speaker and he explains this format really well. But we’re going to continue to talk about this throughout the rest of the course because we’re going to refer to other ways to visualize our frontend application specifically. And if you like to read an article that I wrote that talks about how the modifications I like to made to the C4 model for frontend systems, I link to that in the description as well.