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