Monolith

- [Instructor] The monolith is a fairly simple architectural pattern. A monolith is an application that consists of a single executable that is deployed as a whole. Of course, the single executable can contain other components that it needs, but they are deployed and executed together. This single application contains all the logic to solve the problem at hand. When a new feature is requested, it is coded into this project. Even though the mullet has a bad reputation, it does have advantages when applied correctly. First, it's a simple architecture that is easy to understand, implement, and test. Because of its simplicity, it's usually easy to deploy. There isn't much need for coordination with other systems or teams, and this makes it ideal for projects with a limited scope. But once the application starts to grow, the disadvantages can become apparent. In a monolith, tight coupling is easily introduced by accident, this makes it harder to move pieces of logic to other applications later. Even though the monolith doesn't mean complex code by definition, it has often led to situations where developers find it hard to modify or extend the application. And another disadvantage of the monolith is that it can lead to a one-size-fits-all approach. Some parts of the application might benefit from being developed with other patterns and technologies, but the monolith will make this a difficult thing to do. Let's have a look at a monolithic application. In the exercise files, open the monolithic solution in Visual Studio. Before running the application, run the recreate database script. This will give us a fresh empty database. Then after the solution has opened, in Visual Studio, open the debug menu and select start without debugging. What you'll see is a website for a fictional travel agency. We can list the tours, select one to learn more about it, and even try to create a booking. Now, once the booking has been made, we can navigate to our app data folder, and we'll see that three files are present. One is the database and the other two, the text files, contain details of a fictional call to a mail server or an external API. To verify that a booking has actually been made, we can run the show booking scripts. And as you can see, one record has been added. Now let's look at the code. In the Solution Explorer, we can see that the code has been organized into several folders. Everything starts with a page. For example, the tours.cshtml page. This contains the UI markup and any UI logic that is necessary. Then if you go to the code behind file, we can see online 19 that we call a get-tours method on a repository. We can find the repository in the data access folder, and this class contains the logic to connect to the database and get the tours and return it to us for the UI. There's also a domain folder, which contains our domain classes, tour and booking, and we also have a services folder which contains all logic to connect to external services. Regardless of how the code is organized, this will all be compiled into a single executable. It contains logic for the user interface, the database, external APIs, sending emails, and any business logic. Remember, the monolith may have a bad reputation, but a monolith is not synonymous with badly-structured code. It's perfectly possible to build a clean monolith and let it evolve into other architectural patterns when necessary.