Loading...
...
Posted by Firuza Polad on june 10, 2025

N-Layer Architecture

N-Layer Architecture, also known as Multilayer Architecture, separates an application into distinct logical layers, each with its own responsibility. Each layer performs a single function and communicates only with the layer directly above or below it. There are two main variations: Tightly Coupled N-Layer—where layers call each other directly without abstractions, and the business logic depends directly on EF/DAL; The request starts at the UI, passes through the Business Layer, down to the Data Access Layer, and returns along the same path. The Business Layer can directly reference the DAL. and Loosely Coupled N-Layer —where the Service layer separates coordination from domain logic using interfaces, making the system more testable and maintainable. In this model, the UI layer communicates with the Service Layer instead of BL which allow DI, in return Service layer depend on Interface defined in Domain layer, and Infrastructure layer provides the concrete implementation. Service layer does not have a direct dependency to implementation of interface.

...

Typical Flow for Tightly Coupled N-Layer


...

Tight 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).

...

Typical Flow for Loosely Coupled N-Layer


...

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.

...

Typical Flow for Onion Architecture

...

Onion Folder 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.

...

Typical Flow for Clean Architecture

...

Clean Folder 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.

Information
All diagrams, Folder structure, Code example in this blog were created by me using Lucid , Canva and IDE If you'd like to contribute, request more diagrams or text, or suggest improvements, feel free to contact me
© 2025 Firuza Polad. All rights reserved.

Let’s Connect

I’m open to collaboration, remote and freelance work!