معماری تمیز (Clean Architecture)

مشکل: منطق کسب‌وکار در همه جا

فروشگاه اینترنتی ما سه سال است کار می‌کند. قانون «جمع سفارش حداکثر ۲۰ میلیون تومان» کجای کد است؟ برنامه‌نویس جدید جستجو می‌کند و این را پیدا می‌کند:

• یک بار در کنترلر سفارش. قبل از ذخیره چک می‌شود.
• یک بار در یک Stored Procedure. کسی سال پیش اضافه کرده است.
• یک بار در کلاسی که با EF Core کار می‌کند. با یک عدد کمی متفاوت.

حالا چند مشکل داریم:

1. تست قانون بدون دیتابیس و وب ممکن نیست. قانون به کنترلر و DbContext چسبیده است.
2. تغییر ابزار، منطق را عوض می‌کند. اگر از EF Core به Dapper برویم، قانون‌ها هم باید جابه‌جا شوند.
3. هیچ کس جای درست را نمی‌داند. هر نفر قانون جدید را جایی که راحت‌تر است می‌نویسد.

معماری تمیز یک جواب ساده به این سؤال می‌دهد: هر چیز کجا باشد و به چه چیزی وابسته باشد؟

ایده: پیاز و قانون وابستگی

برنامه را مثل یک پیاز در چند حلقه ببین. مهم‌ترین و پایدارترین کد در مرکز است. جزئیاتی که زیاد عوض می‌شوند، بیرون هستند.

یک قانون اصلی همه چیز را نگه می‌دارد. به آن قانون وابستگی (Dependency Rule) می‌گوییم:

چرا این قانون مفید است؟

1. مرکز پایدار است. قانون «سقف ۲۰ میلیون» سال‌ها تغییر نمی‌کند، ولی نسخه EF Core هر سال عوض می‌شود.
2. تغییرهای بیرونی به داخل نمی‌رسند. وقتی دیتابیس عوض شود، فقط حلقه بیرونی عوض می‌شود.
3. تست ساده می‌شود. دامنه و کاربرد را بدون دیتابیس و بدون وب‌سرور تست می‌کنی.

چهار لایه، با یک مثال

لایه دامنه همان جایی است که ایده‌های درس DDD زندگی می‌کنند: Entity، Value Object و Aggregate. معماری تمیز می‌گوید این کد کجا باشد. DDD می‌گوید این کد چطور نوشته شود. این دو با هم خوب کار می‌کنند، ولی هر کدام بدون دیگری هم قابل استفاده است.

چطور دامنه به دیتابیس نیاز ندارد؟

سؤال مهم این است: لایه کاربرد باید سفارش را ذخیره کند. ولی اجازه ندارد EF Core را بشناسد. پس چطور؟

جواب همان وارونگی وابستگی در درس SOLID است:

1. لایه کاربرد یک اینترفیس تعریف می‌کند. این اینترفیس می‌گوید «من به چیزی نیاز دارم که سفارش را بیاورد و ذخیره کند».
2. لایه زیرساخت آن را پیاده‌سازی می‌کند. کلاس EfOrderRepository با EF Core کار می‌کند.
3. لایه ارائه این دو را در DI به هم وصل می‌کند. فقط این لایه هر دو را می‌شناسد.

نکته جالب این است: مسیر اجرا و جهت وابستگی با هم فرق دارند. در زمان اجرا، درخواست از API به دیتابیس می‌رود. ولی در کد، زیرساخت به اینترفیس کاربرد وابسته است.

کد

ساختار پروژه‌ها

هر لایه یک پروژه جدا است. ارجاع‌ها همان قانون وابستگی را با کامپایلر اجرا می‌کنند:

<!-- Shop.Application.csproj -->
<ItemGroup>
  <ProjectReference Include="..\Shop.Domain\Shop.Domain.csproj" />
</ItemGroup>

<!-- Shop.Infrastructure.csproj -->
<ItemGroup>
  <ProjectReference Include="..\Shop.Application\Shop.Application.csproj" />
  <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="10.0.0" />
</ItemGroup>

پروژه Shop.Domain هیچ ارجاعی ندارد. نه به EF Core و نه به هیچ پروژه دیگر.

دامنه

namespace Shop.Domain;

public sealed class Order
{
    private const decimal MaxTotal = 20_000_000;
    private readonly List<OrderLine> _lines = [];

    public Guid Id { get; } = Guid.NewGuid();
    public IReadOnlyList<OrderLine> Lines => _lines;
    public decimal Total => _lines.Sum(line => line.Price * line.Quantity);

    public void AddLine(Guid productId, decimal price, int quantity)
    {
        if (Total + price * quantity > MaxTotal)
            throw new DomainException("Order total is over the limit.");

        _lines.Add(new OrderLine(productId, price, quantity));
    }
}

کاربرد

namespace Shop.Application.Orders;

public interface IOrderRepository
{
    void Add(Order order);
    Task SaveChangesAsync(CancellationToken ct);
}

public sealed record PlaceOrderCommand(IReadOnlyList<CartItem> Items);

public sealed class PlaceOrderHandler(IOrderRepository orders)
{
    public async Task<Guid> HandleAsync(PlaceOrderCommand command, CancellationToken ct)
    {
        var order = new Order();
        foreach (var item in command.Items)
            order.AddLine(item.ProductId, item.Price, item.Quantity);

        orders.Add(order);
        await orders.SaveChangesAsync(ct);
        return order.Id;
    }
}

لایه کاربرد قانونی را خودش چک نمی‌کند. فقط کار را هماهنگ می‌کند: بساز، به دامنه بسپار، ذخیره کن.

زیرساخت

namespace Shop.Infrastructure;

internal sealed class EfOrderRepository(ShopDbContext db) : IOrderRepository
{
    public void Add(Order order) => db.Orders.Add(order);

    public Task SaveChangesAsync(CancellationToken ct) => db.SaveChangesAsync(ct);
}

public static class DependencyInjection
{
    public static IServiceCollection AddInfrastructure(
        this IServiceCollection services, string connectionString)
    {
        services.AddDbContext<ShopDbContext>(options => options.UseSqlServer(connectionString));
        services.AddScoped<IOrderRepository, EfOrderRepository>();
        return services;
    }
}

کلاس EfOrderRepository به شکل internal است. هیچ پروژه دیگری نمی‌تواند مستقیم از آن استفاده کند.

ارائه

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddScoped<PlaceOrderHandler>();
builder.Services.AddInfrastructure(builder.Configuration.GetConnectionString("Shop")!);

var app = builder.Build();

app.MapPost("/orders", async (PlaceOrderCommand command, PlaceOrderHandler handler, CancellationToken ct) =>
{
    var id = await handler.HandleAsync(command, ct);
    return TypedResults.Created($"/orders/{id}", id);
});

app.Run();

قانون‌های مهم

1. دامنه هیچ ارجاعی ندارد. نه EF Core، نه ASP.NET Core، نه هیچ کتابخانه زیرساختی.
2. اینترفیس مال کسی است که از آن استفاده می‌کند. اینترفیس مخزن در کاربرد است، نه در زیرساخت.
3. قانون کسب‌وکار در دامنه است. نه در کنترلر، نه در Handler، نه در دیتابیس.
4. فقط لایه ارائه همه را می‌شناسد. این لایه جایی است که همه چیز در DI به هم وصل می‌شود.
5. مرز را با ابزار چک کن. ارجاع پروژه‌ها بیشتر اشتباه‌ها را می‌گیرد. برای قانون‌های دقیق‌تر، تست معماری با کتابخانه‌هایی مثل NetArchTest یا ArchUnitNET بنویس.

اشتباه‌های رایج

چه وقت معماری تمیز؟