 So now that we have understood what the main questions, what the main concerns are when we do an architecture, we go into these things that have called architectural patterns or styles. It's used interchangeably, so you can say either architectural styles is maybe more common. And what they are, is essentially good practice. So it's some kind of practice that has been used in different contexts. We know that it works in certain ways. We know what the trade-offs are. For example, if it gives us more performance or more security, we of course also know what the disadvantages are, but essentially it's a record of what is good practice. And we go into five of them and the first one we look into is called the model view controller style, which you have probably already heard of. And as the name says, we have three elements. We have the controller. We have the model. We have the view. So this is the model view controller or MVC pattern. There are variants of this nowadays. This one has a couple of disadvantages, but it has evolved a bit. So you might hear other things like MVVP or so, but they are related at least. Now, what we do in the model view controller is essentially we try to have the data, the state of our data, which is here in the model, independent from the view of the representation of it and the way we control it as well. So for example, you might have a certain data here. I mentioned the web shop earlier. So you might have a shop where you buy different things. And you could have a website for that, but you could also have a mobile application. And depending on which one you use, you might have different views. It might look differently. And this means you don't have to somehow copy everything, but as a central, for example, one or many databases where the data, the actual state of your shop is, but you have multiple of these views and you can later on add a new one or remove it. So this is very flexible in the sense that the data stays the same, but you can evolve the rest independently. And essentially, you have the data. The view queries it. So it somehow gets the data from a database, for example, and represented in a certain way, for example, a table on a website. The model, if something changes in the data, might also notify the view. So say, listen, my data has changed. Please reload the website, for example. The view is often an event-based thing. So there might be a user event, like a user is buying something. And the view that informs the controller is something that happened. And depending on what has happened, the controller updates the model. So this is usually how it is. The controller might, of course, also trigger an update in the view itself without changing the data. So in general, this is a very common pattern. For example, for websites, for mobile applications, this is extremely common to do. And the advantage here is exactly this separation that you can have the data very differently from how it is represented to the user. And that's not only useful if you have multiple views, like the mobile client and the web client. It's also useful if, for example, the view is developed by a different organization. So you don't really have control over this. Or when you design the model and the controller, you don't really know yet how this will look like. So it might change later. So that's why the Model View Controller is a very nice pattern for this case. Good. So much for MVC. I just wanted to mention it shortly, since many people might have already seen this. The next one we'll go into is another very popular one, it's the layered architecture.