Clean Architecture: Keeping Code Clean and Maintainable

Clean Architecture. If you’ve ever struggled with messy, tightly-coupled code that’s hard to maintain or extend, Clean Architecture can be a real lifesaver. In this post, I want to share some thoughts on why I think it’s important and how I’ve applied it in a payroll processing system.

What is Clean Architecture?

At its core, Clean Architecture is about creating a structure that separates concerns and reduces dependencies between different layers of your application. You can think of it as concentric circles, where the most critical business logic sits at the center, and outer layers handle more technical concerns (like the UI or external frameworks).

Here’s a simple diagram:

       [ Presentation/UI Layer ]   
              ↕
     [ Application/Service Layer ]
              ↕
      [ Domain/Business Logic Layer ]
              ↕
       [ Infrastructure Layer ]

The core idea is that your business logic (Domain) doesn’t know about the outside world (UI, databases, frameworks, etc.). This gives you flexibility to swap out technologies without affecting the core business rules.

Why Is It Important?

I’ve found Clean Architecture incredibly useful in keeping things modular and testable. You don’t want your payroll logic to change just because you’ve switched databases or updated your front-end technology, right? Clean Architecture ensures that each layer of your system has a single responsibility, and that each layer can evolve independently.

Applying Clean Architecture in Payroll Processing

Let me show you how this works using a simple payroll processing example. The goal here is to make sure that the business rules (like calculating employee salaries) are completely isolated from the details of how we store the data or interact with external systems.

1. Domain Layer (Core Business Logic)

This is where we put the actual rules for salary calculation. It shouldn’t care about how the data is stored or how it’s presented.

// Domain Layer: Employee Entity and Payroll Rule
public class Employee
{
    public string Name { get; private set; }
    public decimal BaseSalary { get; private set; }
    public decimal Bonus { get; private set; }

    public Employee(string name, decimal baseSalary, decimal bonus)
    {
        Name = name;
        BaseSalary = baseSalary;
        Bonus = bonus;
    }

    public decimal CalculateTotalSalary()
    {
        return BaseSalary + Bonus;
    }
}

In this example, the Employee class contains the core logic for calculating the total salary. Notice how there’s no mention of databases, UI, or anything else—this is just pure business logic.

2. Application Layer (Use Cases)

Now we need to add some use cases. The Application Layer orchestrates the business logic and provides high-level operations like processing a salary. Again, this layer doesn’t know where the data comes from.

// Application Layer: Salary Processor
public class SalaryProcessor
{
    private readonly IEmployeeRepository _employeeRepository;

    public SalaryProcessor(IEmployeeRepository employeeRepository)
    {
        _employeeRepository = employeeRepository;
    }

    public decimal ProcessEmployeeSalary(int employeeId)
    {
        var employee = _employeeRepository.GetById(employeeId);
        return employee.CalculateTotalSalary();
    }
}

Here, the SalaryProcessor interacts with the IEmployeeRepository, which is an abstraction for data access. This keeps the application logic focused on business operations, without getting tangled in how the employee data is stored or retrieved.

3. Infrastructure Layer (Data Access)

Finally, we have the Infrastructure Layer. This layer knows about the details of databases, file systems, or any other technical concern. The key is that it implements the interfaces defined in the higher layers.

// Infrastructure Layer: Employee Repository Implementation
public class EmployeeRepository : IEmployeeRepository
{
    public Employee GetById(int employeeId)
    {
        // Normally this would involve fetching data from a database.
        // But for this example, let's return a dummy employee.
        return new Employee("John Doe", 3000m, 500m);
    }
}

The EmployeeRepository class is where the actual data fetching happens. It could be from a database, an API, or even a file system. The SalaryProcessor doesn’t care about that—it just uses the IEmployeeRepository to get the data it needs.

4. Presentation Layer (UI)

In a real-world application, you might expose this logic through a web API or a desktop app. The UI layer will just call the SalaryProcessor to get the calculated salary and display it.

// Presentation Layer: Example of calling the Salary Processor
public class PayrollController
{
    private readonly SalaryProcessor _salaryProcessor;

    public PayrollController(SalaryProcessor salaryProcessor)
    {
        _salaryProcessor = salaryProcessor;
    }

    public void DisplayEmployeeSalary(int employeeId)
    {
        var totalSalary = _salaryProcessor.ProcessEmployeeSalary(employeeId);
        Console.WriteLine($"The total salary for employee {employeeId} is {totalSalary}");
    }
}

Here, the PayrollController is the entry point for the user interface. It calls into the SalaryProcessor to get the salary and then prints it to the console. You could easily swap this for a web API or a desktop app UI without touching the business logic.

Key Benefits of Clean Architecture

1. Testability: Since the business logic is isolated, it’s super easy to write unit tests without worrying about databases or other infrastructure concerns.

2. Flexibility: You can switch out the data layer (e.g., change databases or add caching) without affecting the business rules or application logic.

3. Separation of Concerns: Each layer has a well-defined responsibility, making the system easier to understand and maintain.

Final Thoughts

Clean Architecture might seem overkill for small projects, but as your system grows, you’ll appreciate how it helps keep things modular and maintainable. It’s especially useful when your business logic is complex or you foresee the need to switch technologies (like moving from SQL to NoSQL, or from desktop to web).

By keeping your business rules at the center, you protect your core logic from changes in external technologies. That’s something I’ve really come to value.

If you’re not using Clean Architecture yet, I’d highly recommend giving it a try. Start small, apply the principles where they make sense, and see how it impacts your code quality.

Keep coding!!