All in One (Monolithic)

“All-in-one architecture” typically refers to a design approach or system where multiple functionalities or components are integrated into a single solution or platform. In software development, an all-in-one architecture might refer to a comprehensive software package that combines several features or modules into one cohesive application. For example, an all-in-one software for project management might include task tracking, scheduling, document sharing, and communication tools all within a single interface.

V If we’re being specific to Microsoft, then all code is contained in one (large) Visual Studio Project

! File > New Project approach

X As requirements grow, the size of the application grows

X Layers can be added using different folders, but eventually issues will arise due to the nos. of folders, thus making it difficult to maintain.

Although one developer can try and stick to the convention based folder usage, but what will happen if we have multiple developers working.

Mediator Pattern

When we have different Classes, that need to use or class functions of other classes, then one way is to start creating objects of a class in the other and using those, resulting in the following spaghetti

Or to make it simpler we can use mediator pattern to resolve this issue by introducing mediator in the middle. The mediator will encapsulate how the other objects were interacting with one another, so if one object wants to call another object function it will call the mediator instead and try and have that function called via the mediator.

Now to implement this we already have a library MediatR. Its a simple mediator implementation. 

Mediator has two approaches

• Request/Response approach
• Notification approach (not now)

Request/Response Approach

Imaging 2 requests, Request#1 and Request#2, now the mediator receives the requests, and accepts those. Once it does, the requests are forwarded to the appropriate handlers. One handler just accepts requests addressed for it, now how the handler is called is managed by the MediatR

Layered Architecture

Layered architecture, also known as layered software architecture or multitier architecture, is a design pattern commonly used in software development. It divides an application into distinct layers, each responsible for specific tasks and with well-defined interfaces between them. This approach helps to organize and structure complex systems, making them easier to understand, maintain, and scale.

Here are the typical layers found in a layered architecture:

1. Presentation Layer: This is the topmost layer that interacts with users or external systems. It handles user input, displays information to users, and translates user actions into operations that the underlying layers can understand. This layer often includes user interfaces, such as web pages, mobile apps, or desktop interfaces.
2. Application Layer (Business Logic Layer): The application layer contains the business logic or the core functionality of the application. It processes and coordinates tasks, enforces business rules, and manipulates data based on the inputs received from the presentation layer. This layer acts as an intermediary between the presentation layer and the data layer, ensuring that business processes are properly executed.
3. Data Access Layer: Also known as the persistence layer, this layer is responsible for interacting with the data storage systems, such as databases or external APIs. It handles tasks related to data retrieval, storage, and manipulation, abstracting the underlying data sources from the rest of the application. This separation allows for easier maintenance and flexibility in changing the data storage mechanisms without impacting other layers.

Almost all application apply layering, even the all-in-one does as well.

The layers are still dependent on one and another, although layered but still the application is tightly coupled. So the whole application breaks if one

Clean Architecture

It is an approach to building software systems that emphasizes separation of concerns, testability, maintainability, and independence of external frameworks and libraries. Clean Architecture provides a clear structure for organizing code, making it easier to understand, maintain, and extend over time.

At the heart of Clean Architecture is the concept of dependency inversion, which involves arranging the components of a system so that higher-level modules do not depend on lower-level modules directly. Instead, both higher-level and lower-level modules depend on abstractions. This allows for more flexibility and easier substitution of components, as well as making the codebase less coupled and easier to test.

Clean Architecture typically consists of several layers, with each layer having a specific responsibility and depending only on the layers beneath it. These layers can vary depending on the specific requirements of the application, but a common arrangement includes:

1. Entities: This layer contains enterprise-wide business rules and domain models. Entities represent the core concepts and data structures of the application.
2. Use Cases (Interactors): Use cases encapsulate the application’s business logic. They orchestrate the flow of data and operations between entities and external systems, implementing specific application functionalities.
3. Interface Adapters: Interface adapters convert data from the format most convenient for the use cases and entities into the format most convenient for external systems, such as databases, user interfaces, or third-party services. This layer includes presenters, controllers, and data mappers.
4. Frameworks and Drivers: This layer contains external frameworks, libraries, and tools necessary for the application to run, such as web frameworks, databases, or communication protocols. These components are kept at the outermost layer to minimize their impact on the rest of the system and allow for easy substitution or updates.
   It looks like an onion architecture

We start from the middle and work our way up/outside. In the middle lies the Core (Application Core + Interfaces Entities)

Application Core(Interface Entities + Application Core)

• Abstractions (high-level)
• Interfaces and entities
• Business logic at the center of the application (use-cases)
• Agnostic to outer circles
• Has no dependencies on external influences

Outer Core (UI + Infrastructure)

• Depends on Core
• Implements interfaces from Core
• Dependencies are inverted,

Following go inside the Infrastructure

• Data access (EF Core)
• Logging
• API Clients
• Identity

while following go inside the UI
– API/MVC/Razor 
– Specific ASP.NET Core items 
 - Middleware 
 - Filters 
– Interact with services through MediatR
 - Loose coupling
 - Lightweight controllers