 Hi, let's start to investigate architectural styles or patterns. One of the easy-to-understand architectures that are used in nowadays solutions, especially when security is a priority, is the layered architecture. Here you see an example of a simple layered architecture. That architecture organizes the system into layers with a related functionality associated with each layer. A layer provides services to the layer above it, so the lowest-level layers represent core services that are likely to be used throughout the system. In this case, for a presentation layer to show the data from a database, the presentation layer must invoke the business layer. The business layer should invoke the data access layer. And in the last step, the data access layer uses the database layer to get the actual data that will be provided to the presentation layer after some processing within the inner layers. Let's take a look at the simple example that you can find in a GitHub repository. Here you see the project of that example. You can look at the bottom of the page to see the structure of that application. It looks similar to the layers I have shown you. Here we have presentation layer that is implemented using Angular 5 framework. The business layer that uses express technology and the MongoDB database. So let's start from the beginning. Let's take a look at the presentation layer. The index.html is the main file here. And what we will see when we open this application, there will be text displayed as layered architecture application and there will be an input field which asks to enter the email. Also there will be a button, load profile and when we click that button, the function get data from business layer will be executed. So now let's take a look at the frontend application. Here we see the function I mentioned before, get data from business layer. It uses the Ajax function to call the URL here. So basically it will call the server hosted on the local computer and it will call the API and point called get user following by the provided email. And if the function will be successful, then the all received information will be presented to the user in the browser. Okay, now let's take a look at this function, get user. It resides in the business layer. So here we see one file. In the beginning we see all the libraries that are used. So basically the business layer uses express framework and also it uses the Mongoose framework to access MongoDB. And it accesses the data layer and the data dedicated for the user. So here we see that endpoint. So basically if URL has this keyword followed by the parameter, then we will call the data layer and we will call the function get user by email from that data layer. So let's take a look at our data layer. We see the data structure that is used for the user and we see the function get user by email. It uses the function find one to get the user by email and provides the data back to the business layer. So after business layer gets the data, it will provide the OK or 200 status for the browser and also it will return the information about the user and go that using the JSON format. Now our presentation layer will decode that information and present it in a web browser. We are back and I have a question for you. Do you see any problem or inconvenience? OK, as you probably noticed, when using this architecture, we cannot invoke any layer we want directly. All intermediate layers should be accessed. Sometimes it's a waste of a development effort and software performance. It becomes the single anti-pattern. The 80-20 rule says that if there are more than 20% of pass-through requests, the solution experiences the single anti-pattern. So what can be done? The solution is to identify the layers that are allowed to bypass. Take a look at this picture. The layers have open closed states. If the layer is closed, it is necessary to access it. If the layer is open, just like the service layer, it is possible to skip it. In this manner, the engineers are able to fine-tune the software architecture to avoid the anti-pattern. Still, keep in mind that it will not be always possible. Let's review the main benefits of layered architecture. Abstraction. Layers allow changes to be made at the abstract level. You can increase or decrease the level of abstraction you use in each layer of the hierarchical stack. Abstraction allows you to isolate technology upgrades to individual layers in order to reduce risk and minimize the impact on the overall system. Manageability. Separation of core concerns helps to identify dependencies and organizes the code into more manageable sections. Stability. Roles promote reusability. Separation of concerns. It's a key component of building layered applications. And the stability. Increased stability arises from having well-defined layer interfaces as well as ability to switch between different implementations of the layer interfaces. Separated presentation patterns allow you to build mock-up objects that mimic the behavior of concrete objects. Let's look at the key takeaways of this lecture. The layered architecture organizes the system into layers with related functionality associated with each layer. A layer provides services to the layer above it, so the lowest-level layers represent core services that are likely to be used throughout the system. Any application may consist of separate logical layers, used when building new facilities on top of existing systems. When the development is spread across several teams, with each team responsibility for a layer of functionality, when there is a requirement for multi-level security, it allows replacement of entire layers so long as the interface is maintained, allows separation of concerns, isolation, manageability, reusability, and stability. In practice, providing a clean separation between layers is often difficult. A high-level layer may have to interact directly with lower-level layers, rather than through the layer immediately below it. Performance can be a problem as well. Thank you for watching.