Architecture Deep Dive

N-Layer Architecture

FLOW: TIGHTLY COUPLED

FOLDER STRUCTURE

Presentation Layer (UI): Displays data to users, handles user inputs, and forwards them for processing (e.g., Controllers, Views, Razor Pages).
Business Layer (Domain): Core business logic and rules; includes Entities, Value Objects, Domain Services/Events (e.g., Book, PriceChangedEvent).
Data Access Layer (DAL): Handles data persistence and CRUD operations, including Repositories and Migrations (Repository + DB).

FLOW: LOOSELY COUPLED

FOLDER STRUCTURE

Presentation Layer (UI): Handles UI concerns (e.g., Controllers, Views, Razor Pages)
Application Layer: Acts as a bridge between UI and Domain, containing use-case coordination logic (e.g., BookAppService)
Business Layer (domain): Contains the core business rules, entities, and domain logic.
Data Access Layer (DAL): Manages data persistence and database interactions.

Code Example for Tightly Coupled

Controller: Handles the HTTP request and forwards it to the application service.
Service: Contains domain logic for creating books.
Reposiory: Performs CRUD operations using Entity Framework. Database stores book data.

Code Example for Loosely Coupled

Controller: Handles the HTTP request and forwards it to the application service
Service: Acts as a bridge between the UI and domain logic, coordinates tasks.
Interface: UI layer communicate with Application layer help of Interface.
Reposiory: Performs CRUD operations using Entity Framework. Database stores book data.

Clean Architecture

This architecture aims to create system to ensure that different part of codebase are independent of each other, making it easier to change and extend without breaking thing. In here each layer has its own role, and wont affect the others. It has Core Business logic and Outer layer, and emphasizes Inward dependencies - Core logic does not depend on Outer layer (like Db), but Outer layer depend on the core.

• Core Business Logic: It means what the application does. It should not depend on anything external like APIs or frameworks.
• Outer layer: Like DB, UI, external services. This depend on core logic, but core logic does not depend on them.

Onion Architecture

This architecture aims to keep the core business logic isolated from external layers such as DB, UI, Frameworks. Both, Clean architecture and Onion architecture share dependencies point inward to Core, meaning both contain domain entities; Core is independent of UI, DB; Outer layer depend on Core, but not vica versa.

ONION FLOW

ONION STRUCTURE

Presentation Layer (UI): Handles user interaction and input/output operation
Application Layer: Handle data flow between the Domain and Infrastructure
Domain Layer (core): Contains core business logic, domain Entites, value object, domain services.
Infrastructure layer: Provide actual implementation of interface defined in domain like Repository,Logging,Catching.

CLEAN FLOW

CLEAN STRUCTURE

Interface adapters (UI):: Translate data between Core business logic (entites, cases) and external system (Db, UI). Converst data format, so Application logic can work with data without care about format, Controller/View.
Application logic (Use cases): It coordinate interaction between entities and outside world. Use Cases, Commands, Queries, AppServices.
Entites (core): The heart of the application, containing business rules, domain entities, value objects. And independent of anything like DB, UI code..
Infrastructure layer: Contains the actual implementation of details. This layer depend on Interface defined in the Core BS logic. Deals with the things that often change, like DB, API, file system etc.

Code Example for Onion architecture

Controller: UI entry point — handles HTTP requests and forwards to Application logic
Service: It orchestrates the flow between UI, Domain logic, and Infrastructure.
Interface: Defines contract for data access
Reposiory: Implements deals with actual data persistence such as DB, API

Code Example for Clean architecture

Controller: Uses AppService. So, Controller only depends on the AppService. Follows dependency inversion.
Service: Use MediatR for separation. Ensure commands/queries have required field
Entites: Books entity and Reposiory interface is defined in Domain Layer.
Infrastructure: Repository implements domain interface which is defined Core logic.

Nlayer architecture vs Onion architecture:

Both use layers like UI,Service,Domain,Data, but they are not the same.
a. In Nlayer architecture : flow is top-down, UI depend on BL in return BL depend on DAL. Controller (UI)->Service(BS)->Repository(DAL)-> Infrastructure(DB). Tight coupling makes swapping hard.
b. In Onion architecture : flow is inward, Outer layer depend on Inner layer(domain), domain must not depend on anything. Domain has no idea what EF is, Repository is just interface in Domain, and Infrastructure implement interface and injects it upward. Controller(UI)->AppService (application) -> Domain (IRepository)-> Infrastructure (implementation) Easy to swap Infrastructure without touching domain.

Clean architecture vs Onion architecture:

a. In Clean architecture has a special Use Case Layer to define Command/Queries/Handlers. Separation via CQRS, Mediatr is supported. Emphasize use-case driven architecture.
b. In Onion architecture the application logic is often part of services. Seperation is Optional, often declared in services.
NOTE: Use Cases- describe specific user goals or tasks that the system supports. Example: imagine online store, here some Use Cases are: create order, process payment, update account details.