DEV Community: Pouria Ghadiri

Onion Architecture in .NET Core: Keeping Your Core Clean (Part 3)

Pouria Ghadiri — Thu, 05 Jun 2025 18:08:25 +0000

Onion Architecture in .NET Core: Keeping Your Core Clean (Part 3)

Alright, here we go—part three! If you’ve been following along, you already know why good architecture matters and how the old-school layered thing works. Now let’s talk about Onion Architecture. This one’s a game-changer if you’re sick of spaghetti code or business logic that’s tangled with database weirdness.

So, What’s Onion Architecture Anyway?

Picture this: your app is an onion (cue the Shrek jokes). The juicy stuff—your domain, the business rules—sits in the middle. Everything else? Just layers wrapping around, like armor. The golden rule: dependencies only point inwards. That means your core logic couldn’t care less about which database you use, what the UI looks like, or what random third-party library you’ve glued on.

Why bother? Clean core. If you want to swap out your database, you can. If the latest JavaScript framework drops and everyone loses their minds, your business rules don’t flinch. No more pollution from infrastructure code sneaking into your logic.

Why Use It?

Because it keeps your business logic clean and untouched by infrastructure chaos. If you’re switching from SQL Server to PostgreSQL, no problem. Building a new UI? Go for it. The core remains the same.

Core Principles of Onion Architecture

The domain (business logic) sits at the center.
Each layer wraps around the one inside it.
Outer layers depend on inner ones—not the other way.
Infrastructure is plugged in via interfaces.
Code stays clean, testable, and easy to reason about.

How the Layers Stack Up

Here’s a quick look at the architecture:

Center: Domain Layer (Entities, Interfaces, Business Rules)
Next Layer: Application Layer (Use Cases, Services)
Outer Layer: Infrastructure Layer (Database, Email, Logging)
Outermost: Web/API/UI Layer (Controllers, Views, Pages)

Each layer only talks to the one just inside it. That’s the key.

A Simple .NET Project Structure

Your folders might look like this:

/MyApp
  /Domain
    Order.cs
    IOrderRepository.cs
  /Application
    OrderService.cs
    IOrderService.cs
  /Infrastructure
    OrderRepository.cs
    EmailSender.cs
  /WebAPI
    OrdersController.cs

Straightforward and clean.

Quick Code Peek

Domain Layer
Defines your Order entity and a repository interface—no database stuff here.

public class Order {
    public Guid Id { get; set; }
    public decimal Total { get; set; }
    public DateTime CreatedAt { get; set; }
}

public interface IOrderRepository {
    Task SaveAsync(Order order);
}

Application Layer
Handles business use cases—like creating an order—but stays blissfully ignorant about where that order gets saved.

public interface IOrderService {
    Task<Guid> CreateAsync(decimal total);
}

public class OrderService : IOrderService {
    private readonly IOrderRepository _repository;

    public OrderService(IOrderRepository repository) {
        _repository = repository;
    }

    public async Task<Guid> CreateAsync(decimal total) {
        var order = new Order {
            Id = Guid.NewGuid(),
            Total = total,
            CreatedAt = DateTime.UtcNow
        };

        await _repository.SaveAsync(order);
        return order.Id;
    }
}

Infrastructure Layer
This is where you actually touch the database. It implements those interfaces from the Domain layer.

public class OrderRepository : IOrderRepository {
    private readonly AppDbContext _context;

    public OrderRepository(AppDbContext context) {
        _context = context;
    }

    public async Task SaveAsync(Order order) {
        _context.Orders.Add(order);
        await _context.SaveChangesAsync();
    }
}

Web/API Layer
Takes HTTP requests, calls your service, returns IDs. No business logic hiding in here.

[ApiController]
[Route("api/[controller]")]
public class OrdersController : ControllerBase {
    private readonly IOrderService _orderService;

    public OrdersController(IOrderService orderService) {
        _orderService = orderService;
    }

    [HttpPost]
    public async Task<IActionResult> Create(decimal total) {
        var id = await _orderService.CreateAsync(total);
        return Ok(id);
    }
}

Onion vs Layered Architecture

Here’s a quick comparison:

Feature	Layered Architecture	Onion Architecture
Dependency Direction	Top-down	Inward only
Domain Focus	Not enforced	Core of everything
Testability	Average	Excellent
Infra Isolation	Weak	Strong
Code Reuse	Low	High

When Should You Use It?

If your app has more logic than just CRUD.
If you care about testability and clean architecture.
If you're building APIs or microservices.
If you want to avoid vendor lock-in (like a specific DB).

Migrating from Layered to Onion

Already have a layered structure? Here’s how to begin:

Move your business logic into a Domain project.
Use interfaces to abstract data and external services.
Use dependency injection to wire it all up.
Refactor slowly, step-by-step.

Final Thoughts

Onion Architecture is like giving your business logic its own safe room. Everything else works around it, but can’t mess with it. If you’re tired of fragile, messy code, this approach might just be what you need.

Next up in our series: Clean Architecture. Stay tuned!
Have questions or use this in production? Let’s discuss in the comments!

Layered Architecture in ASP.NET Core: Simple, Structured, and Still Relevant (Part 2)

Pouria Ghadiri — Thu, 22 May 2025 19:00:26 +0000

In the first part of this series, we explored why software architecture matters—especially in .NET projects that grow beyond simple CRUD applications.

Today, we’re starting with one of the most familiar patterns: Layered Architecture. It’s often the first structured approach developers learn—and with good reason. It brings clarity and separation of concerns without much overhead.

Let’s break it down.

What Is Layered Architecture?

Layered Architecture, also known as n-tier architecture, separates your application into logical layers where each layer has a specific responsibility.

A typical ASP.NET Core project using this pattern includes:

Presentation Layer (e.g., Controllers, Razor Pages, APIs)

Application Layer (e.g., Services, Business Logic)

Data Access Layer (e.g., Repositories, EF Core)

Domain Layer (optional, for core models and logic)

+-----------------------+
|   Presentation Layer  |
|  (Controllers / API)  |
+-----------------------+
           ↓
+-----------------------+
|   Application Layer   |
| (Services / Use Cases)|
+-----------------------+
           ↓
+-----------------------+
|   Data Access Layer   |
|   (EF Core / DB Code) |
+-----------------------+

Each layer only talks to the layer directly below it.

Why Use Layered Architecture?

✅ Separation of concerns
✅ Improves maintainability
✅ Simplifies testing (especially service logic)
✅ Well-supported in tutorials, teams, and tooling

It helps you avoid the "God Controller" or "fat service" problems by pushing logic to the right place.

Common Mistakes

Despite its simplicity, developers often misuse this pattern:

❌ Skipping the application layer, putting logic in controllers

❌ Services that just forward calls to the database

❌ Tight coupling between layers

❌ Ignoring validation and business rules

🛠️ A Simple Example in ASP.NET Core

Let’s say we’re building a basic order system.

1 Domain Models

public class Order
{
    public Guid Id { get; set; }
    public DateTime CreatedAt { get; set; }
    public decimal TotalAmount { get; set; }
}

2 Application Layer

 public interface IOrderService
{
    Task<Guid> CreateOrderAsync(OrderDto dto);
}

public class OrderService : IOrderService
{
    private readonly IOrderRepository _repository;

    public OrderService(IOrderRepository repository)
    {
        _repository = repository;
    }

    public async Task<Guid> CreateOrderAsync(OrderDto dto)
    {
        var order = new Order
        {
            Id = Guid.NewGuid(),
            CreatedAt = DateTime.UtcNow,
            TotalAmount = dto.Total
        };

        await _repository.AddAsync(order);
        return order.Id;
    }
}

3 Data Access Layer

public interface IOrderRepository
{
    Task AddAsync(Order order);
}

public class OrderRepository : IOrderRepository
{
    private readonly AppDbContext _context;

    public OrderRepository(AppDbContext context)
    {
        _context = context;
    }

    public async Task AddAsync(Order order)
    {
        _context.Orders.Add(order);
        await _context.SaveChangesAsync();
    }
}

4 Presentation Layer (Controller)

[ApiController]
[Route("api/[controller]")]
public class OrdersController : ControllerBase
{
    private readonly IOrderService _orderService;

    public OrdersController(IOrderService orderService)
    {
        _orderService = orderService;
    }

    [HttpPost]
    public async Task<IActionResult> CreateOrder([FromBody] OrderDto dto)
    {
        var id = await _orderService.CreateOrderAsync(dto);
        return Ok(id);
    }
}

Folder Structure

/MyApp
  /Controllers
    OrdersController.cs
  /Services
    IOrderService.cs
    OrderService.cs
  /Repositories
    IOrderRepository.cs
    OrderRepository.cs
  /Models
    Order.cs
    OrderDto.cs

Is Layered Architecture Still Relevant?

Yes—but with nuance.

For small to medium apps, it works great. For complex domains or large teams, it may need enhancements like:

CQRS
MediatR
Onion/Clean Architecture

The key is understanding when it’s enough—and when you need to evolve.

When to Use This Pattern

✅ MVPs or startup products
✅ Internal tools
✅ Projects where complexity is moderate
✅ Teams new to architecture patterns

Up Next

In Part 3, we’ll level up to Onion Architecture—a more flexible structure where dependencies flow inward, not outward.

If Layered Architecture is your first step into designing clean code, Onion Architecture is the next.

Wrap-Up

Layered Architecture is often underestimated, but when done right, it's clean, simple, and effective. It gives your team a structure without overengineering.

Thanks for following along!

Like, comment, or follow for Part 3 coming soon.
Have questions or use this in production? Let’s discuss in the comments!

How I Struggled (and Finally Succeeded) Configuring Redis on Oracle Linux

Pouria Ghadiri — Mon, 19 May 2025 18:18:01 +0000

Spoiler: It took me 1.5 days to do what could’ve been done in an hour—but that’s how you learn!

The Setup

I had two servers:

🖥️ A Linux server (Oracle Linux) where Redis was installed

💻 A Windows server running an application that needed to connect to Redis on port 6379

I thought: "Just install Redis, open port 6379, and boom—it works!"
But no, it wasn't that simple.

First Mistake: Trusting the Defaults
I installed Redis using dnf, which was easy enough. The real challenge started when I tried to connect from the Windows server. The connection kept failing—despite Redis running fine locally on the Linux machine.

I dove into the redis.conf file (the default config file created during installation), and here’s what I had to change:

bind 0.0.0.0
protected-mode no
These two lines are critical:

bind 0.0.0.0: Allows connections from any IP, not just localhost.

protected-mode no: Disables Redis’s "safe mode" that blocks external access.

After applying these changes and running redis-server redis.conf, I connected successfully from the Linux host using redis-cli. All seemed fine.

The Real Error: DENIED by Protected Mode

However, from the Windows server, I still couldn’t connect. A telnet to port 6379returned this error:

DENIED Redis is running in protected mode...

Even though I had disabled protected-mode, Redis still refused the connection.

The missing piece? Authentication.

Fixing It with Docker and a Custom redis.conf
To get more control and test things cleanly, I ran Redis using Docker and created a custom redis.conf:

bind 0.0.0.0
port 6379
daemonize yes
protected-mode no
requirepass MyStrongPassword

✅ That last line—requirepass—was the real key.

Once Redis had a password, everything worked. My application connected successfully from the Windows server.

So here’s a quick checklist for allowing remote connections to Redis:

✅ Edit redis.conf

bind 0.0.0.0
protected-mode no
requirepass your_secure_password
✅ Make sure port 6379is open in the firewall

✅ Restart Redis with the custom config

✅ Test with redis-cli -a your_password -h your_redis_host

What took me 1.5 days could’ve been an hour’s work—but hey, now I really understand Redis’s security model.

If you're setting up Redis for the first time and wondering why remote clients can't connect—check the config. Don't assume it’s the firewall or Docker networking. It's often just a missing requirepass.

Got Tips?

If you have more experience configuring Redis in production or have best practices to share, I’d love to hear from you. This was my first time doing it, and I’m sure there’s room to improve!

I've just started a new article series on software architecture in .NET! My goal is to explain how it works and, more importantly, why it matters. If you're new to concepts like Clean Architecture, DDD, or Onion Architecture—this series is made for you.

Pouria Ghadiri — Sun, 18 May 2025 17:52:42 +0000

Pouria Ghadiri

May 17 '25

Why Software Architecture Matters in Real .NET Projects (Part 1)

#dotnet #csharp #architecture #learning

Comments 2

3 min read

Why Software Architecture Matters in Real .NET Projects (Part 1)

Pouria Ghadiri — Sat, 17 May 2025 19:03:02 +0000

When you’re building an app in ASP.NET Core, it’s easy to fall into the trap of just writing code that “works.” Especially when deadlines are tight. But if you’ve ever looked back at your project and thought, “Ugh, this is a mess,” then you know why architecture matters.
Let me break this down from experience — no buzzwords, just what works in real projects.

🧱 What Is Software Architecture?

Think of software architecture like the blueprint for a house. You wouldn’t build a house without planning where the walls, plumbing, and electrical systems go — same goes for your code.
In .NET, architecture defines how your application is structured : where your business logic lives, how your components talk to each other, and how your app can grow over time without breaking everything.
It’s not about fancy folders or naming things “Service” or “Manager.” It’s about making sure your code stays clean, testable, and easy to change.

👷‍♂️ The Mess We've All Seen

Here’s a common scenario I see all the time:
• Your controller does database calls directly.
• Services just pass data to Entity Framework.
• There’s no clear place for actual business rules.
• Adding a new feature feels risky — like touching one line breaks 10 others.
And here’s what happens as a result:
• Everything is tightly coupled.
• Writing unit tests feels impossible.
• Simple changes take forever.
• New developers struggle to understand the code.
This kind of setup leads to what I call Code Rot — where the codebase gets harder and harder to work with over time.
💥 Example: The God Controller

[HttpPost]
public async Task<IActionResult> Create([FromBody] OrderDto dto)
{
    var order = new Order
    {
        CustomerId = dto.CustomerId,
        Total = dto.Total,
        CreatedAt = DateTime.UtcNow
    };

    _context.Orders.Add(order);
    await _context.SaveChangesAsync();

    return Ok(order.Id);
}

Looks simple enough, right? But think about what happens when you need:
• Validation (is the customer valid?)
• Business rules (e.g., max 5 orders per day)?
• Event logging?
• Sending a confirmation email?
Now your controller becomes a dumping ground for everything. That’s not scalable.

✅ Goals of Good Architecture

Good architecture gives you practical benefits:
• Separation of concerns – Each part has a clear job.
• Testability – You can write unit tests easily.
• Maintainability – Anyone can read and change the code.
• Flexibility – Want to swap out the database or framework later? Easier said than done without good design.
• Scalability – As the app grows, the code doesn't fall apart.
• Clear domain model – Your business logic is obvious, not hidden in random places.
You don’t need to overengineer. Just be thoughtful. A little planning today saves you hours of refactoring tomorrow.

💡 Why This Matters in .NET

Yes, .NET is powerful. Yes, EF Core makes it easy to get started quickly. But most tutorials and templates push you toward patterns like:
• Thin services that just wrap DbContext
• DTOs everywhere with no behavior
• Fat controllers full of logic
These might work for small apps or prototypes, but they don’t scale well. And if your business logic is always changing, or multiple people work on the same code, this approach will slow you down fast.
Architecture becomes even more important when:
• Requirements change often.
• Multiple devs are working on the same project.
• You want a system that’s easy to test and extend.

🔮 What’s Coming Next

In this series, we’ll walk through real architectural patterns used in modern .NET applications — not just theory, but examples you can actually use in your next project.
Here’s what I plan to cover (and I’m committed to delivering):

• Part 2: Layered Architecture – Classic, simple, and still useful.
• Part 3: Onion Architecture – Structure your app so dependencies flow inward.
• Part 4: Clean Architecture – Inspired by Uncle Bob, adapted for .NET.
• Part 5: Domain-Driven Design in .NET – Building meaningful models.
• Part 6+: CQRS, MediatR, Events, Testing Strategies, and Common Mistakes

🚀 Final Thoughts

You don’t have to be at a huge company or working on a massive enterprise system to care about architecture. Even a small app can benefit from a bit of structure.
If you're tired of messy codebases, hard-to-test logic, or struggling to add features without breaking things, this series is for you.
Stick around — we'll turn those spaghetti controllers and thin services into something maintainable, scalable, and enjoyable to work with.