Explain Common web application architectures i.e 1) monolithic application 2) All-in-one applications 3) Layered Architecture 4) Traditional "N-Layer" architecture applications 5) Clean architecture

 Common web application architectures

1)  monolithic application

2)  All-in-one applications

3)  Layered Architecture

4)  Traditional "N-Layer" architecture applications

5)  Clean architecture

1)  monolithic application

• A monolithic application is one that is entirely self-contained, in terms of its behavior.

• It may interact with other services or data stores in the course of performing its operations, but the core of its behavior runs within its own process and the entire application is typically deployed as a single unit.

• If such an application needs to scale horizontally, typically the entire application is duplicated across multiple servers or virtual machines.

2)  All-in-one applications

•  The smallest possible number of projects for an application architecture is one. In this architecture, the entire logic of the application is contained in a single project, compiled into a single assembly, and deployed as a single unit.

• A new ASP.NET Core project, whether created in Visual Studio or from the command line, starts out as a simple "all-in-one" monolith. 

• It contains all of the behavior of the application, including presentation, business, and data access logic. In a single project scenario, separation of concerns is achieved through the use of folders. The default template includes separate folders for MVC pattern responsibilities of Models, Views, and Controllers, as well as additional folders for Data and Services.

3)  Layered Architecture

•  As applications grow in complexity, one way to manage that complexity is to break up the application according to its responsibilities or concerns. This follows the separation of concerns principle and can help keep a growing codebase organized so that developers can easily find where certain functionality is implemented.

• Layered architecture offers a number of advantages beyond just code organization, though. By organizing code into layers, common low-level functionality can be reused throughout the application.

• With a layered architecture, applications can enforce restrictions on which layers can communicate with other layers. This helps to achieve encapsulation. When a layer is changed or replaced, only those layers that work with it should be impacted. By limiting which layers depend on which other layers, the impact of changes can be mitigated so that a single change doesn't impact the entire application.

4)  Traditional "N-Layer" architecture applications

• These layers are frequently abbreviated as UI, BLL (Business Logic Layer), and DAL (Data Access Layer). Using this architecture, users make requests through the UI layer, which interacts only with the BLL.

• The BLL, in turn, can call the DAL for data access requests. The UI layer shouldn't make any requests to the DAL directly, nor should it interact with persistence directly through other means. Likewise, the BLL should only interact with persistence by going through the DAL.

•  One disadvantage of this traditional layering approach is that compile-time dependencies run from the top to the bottom. That is, the UI layer depends on the BLL, which depends on the DAL. This means that the BLL, which usually holds the most important logic in the application, is dependent on data access implementation details (and often on the existence of a database). Testing business logic in such an architecture is often difficult, requiring a test database. The dependency inversion principle can be used to address this issue.

5)  Clean architecture

• Applications that follow the Dependency Inversion Principle, as well as the Domain-Driven Design (DDD) principles, tend to arrive at a similar architecture. It's been cited as the Onion Architecture or Clean Architecture.

•  Clean architecture puts the business logic and application model at the center of the application. Instead of having business logic depend on data access or other infrastructure concerns, this dependency is inverted: infrastructure and implementation details depend on the Application Core.

• This is achieved by defining abstractions, or interfaces, in the Application Core, which are then implemented by types defined in the Infrastructure layer. A common way of visualizing this architecture is to use a series of concentric circles, similar to an onion.

 In the diagram, dependencies flow toward the innermost circle. The Application Core takes its name from its position at the core of this diagram. And you can see on the diagram that the Application Core has no dependencies on other application layers.

The application's entities and interfaces are at the very center.

Just outside, but still in the Application Core, are domain services, which typically implement interfaces defined in the inner circle.

Outside of the Application Core, both the UI and the Infrastructure layers depend on the Application Core, but not on one another (necessarily).