‫Domain-Driven Design (DDD)؛ بخش هشتم: الگوهای Repository و Specification

• شفاف‌سازی کاربرد واحد UnitOfWork
• نویسنده به خوبی تأکید کرده که DbContext یا Context در EF خود رفتار مشابه UnitOfWork را دارد و نیازی نیست لایه دیگری برای آن اضافه کنیم. این تحلیل به درستی ماهیت تراکنش و رفتار EF را برجسته می‌کند.
• به خطر افتادن انسجام تراکنش‌ها
• اگر متدهای .Save() در هر Repository جدا فراخوانی شوند، یک تراکنش واحد به چندین تراکنش تبدیل می‌شود — این می‌تواند منجر به inconsistency شود.
• پیشنهاد جایگزین منطقی
• پیشنهاد استفاده از الگوهای Command/Query که به وضوح مرزها را تعریف می‌کنند، یک رویکرد مدرن و کاربردی برای معماری‌های با پیچیدگی بیشتر است.

• عدم تفکیک بین الگوی Repository و پیاده‌سازی اشتباه آن
• این مقاله به طور کلی استفاده از Repository بر روی Unit of Work را نقد می‌کند، اما باید تاکید بیشتری روی این موضوع می‌کرد که مشکل اصلی، پیاده‌سازی عمومی و بی‌ارزش (Generic Repository) روی یک ORM مدرن است، نه خود الگوی Repository. الگوی Repository هنوز هم در این شرایط بسیار مفید است: زمانیکه بخواهیم لایه دسترسی به داده را از یک تکنولوژی خاص (مثلاً SQL Server) جدا کنیم تا در آینده بتوان آن را با چیز دیگری (مانند یک دیتابیس NoSQL یا حتی یک سرویس خارجی) جایگزین کرد. برای ساده‌سازی تست‌های واحد (Unit Tests) با استفاده از پیاده‌سازی‌های در حافظه (In-memory). زمانیکه کوئری‌ها بسیار پیچیده هستند و کپسوله کردن آن‌ها در یک Repository خاص (و نه عمومی) به خوانایی کد کمک می‌کند.
• عدم درنظر گرفتن تست‌پذیری (Testability)
• همانطور که در کامنت‌ها اشاره شده، Repository به ارائه نوعی از abstraction کمک می‌کند که تست‌پذیری را بهبود می‌دهد.
• مناسب بودن در معماری‌های DDD و بزرگ
• در پروژه‌های بزرگ و با رویکرد Domain-Driven Design یا CQRS، الگوی Repository یکی از اصول بنیادی است و حذف آن در چنین مواردی ممکن است مناسب نباشد.
• حذف کامل Repository ممکن است به پیچیدگی منتهی شود
• عدم وجود یک سطح انتزاع به شکل Repository ممکن است منجر به پراکندگی کد CRUD و تکرار در لایه سرویس یا کنترلر شود؛ مگر اینکه جایگزین مناسبی مثل service generic یا الگوی دیگری در نظر گرفته شود.
• مسأله leakage abstraction و از استفاده از IQueryable
• یک دیدگاه مهم این است که برخی Repositoryهای generic که قابلیت‌هایی مانند .Include و IQueryable را در اختیار می‌گذارند، سبب می‌شوند انتزاع به گونه‌ای "leaky" باشد که وابستگی به ORM را عملاً حفظ می‌کند و قابلیت جابجایی را کاهش می‌دهد.

• اگر پروژه کوچک، ساده و با تراکنش‌های متصل به هم است: حذف لایه Repository و اتکا بر DbContext به‌عنوان UnitOfWork کاملاً منطقی است.
• اگر پروژه بزرگ، چند لایه یا مبتنی بر DDD/CQRS است: استفاده از Repository می‌تواند مزایایی مانند تست‌پذیری و جداسازی لایه‌ها فراهم کند — اما باید همراه با طراحی دقیق و جلوگیری از leaky abstraction باشد.

• جداسازی نگرانی‌ها (Separation of Concerns): منطق پرس‌وجو از لایه سرویس یا کنترلر جدا می‌شود. این باعث می‌شود هر بخش از کد فقط مسئول وظیفه خود باشد.
• قابلیت استفاده مجدد (Reusability): یک کلاس Specification می‌تواند در هر جای برنامه که به آن منطق پرس‌وجوی خاص نیاز است، مجدداً استفاده شود. این از تکرار کد (DRY - Don't Repeat Yourself) جلوگیری می‌کند.
• قابلیت تست (Testability): از آنجایی که هر Specification یک کلاس مستقل است، می‌توان منطق پرس‌وجوی آن را به صورت جداگانه و بدون نیاز به اتصال به پایگاه داده، با استفاده از تست‌های واحد (Unit Tests) آزمایش کرد.
• خوانایی (Readability): نام‌گذاری مناسب کلاس‌های Specification به مستندسازی خودکار کد کمک می‌کند. به جای دیدن یک پرس‌وجوی طولانی LINQ، با یک نام گویا مانند PremiumCustomers2023Spec روبرو می‌شوید که بلافاصله هدف آن را مشخص می‌کند.

var customers = await _dbContext.Customers
    .Where(c => c.IsPremium && c.RegistrationYear == 2023)
    .Include(c => c.Orders)
    .OrderBy(c => c.Name)
    .ToListAsync();

public class PremiumCustomers2023Spec : Specification<Customer>
{
    public PremiumCustomers2023Spec()
    {
        Query.Where(c => c.IsPremium && c.RegistrationYear == 2023)
             .Include(c => c.Orders)
             .OrderBy(c => c.Name);
    }
}

public interface IRepository<T> where T : class
{
    Task<T?> GetAsync(ISpecification<T> spec);
    Task<List<T>> ListAsync(ISpecification<T> spec);
    Task<int> CountAsync(ISpecification<T> spec);
}

public class EfRepository<T> : IRepository<T> where T : class
{
    private readonly DbContext _db;

    public async Task<List<T>> ListAsync(ISpecification<T> spec)
    {
        var query = SpecificationEvaluator.Default.GetQuery(_db.Set<T>().AsQueryable(), spec);
        return await query.ToListAsync();
    }
    // سایر متدها مانند GetAsync و CountAsync به همین شکل پیاده‌سازی می‌شوند.
}

public class ProductFilterSpec : Specification<Product>
{
    public ProductFilterSpec(string? brand, string? type, decimal? minPrice, bool onlyInStock)
    {
        if (!string.IsNullOrEmpty(brand)) Query.Where(p => p.Brand == brand);
        if (!string.IsNullOrEmpty(type)) Query.Where(p => p.Type == type);
        if (minPrice != null) Query.Where(p => p.Price >= minPrice);
        if (onlyInStock) Query.Where(p => p.IsInStock);
        Query.OrderBy(p => p.Name);
    }
}

[HttpGet("products")]
public async Task<ActionResult<List<Product>>> GetProducts([FromQuery] string? brand, string? type, decimal? minPrice, bool onlyInStock = false)
{
    var spec = new ProductFilterSpec(brand, type, minPrice, onlyInStock);
    var products = await _repo.ListAsync(spec);
    return Ok(products);
}

public class AndSpecification<T> : Specification<T>
{
    public AndSpecification(ISpecification<T> left, ISpecification<T> right)
    {
        Query.Where(x => left.IsSatisfiedBy(x) && right.IsSatisfiedBy(x));
    }
}
// اکنون می‌توان Specification‌ها را با هم ترکیب کرد، مثلاً:
// new AndSpecification(new PremiumCustomers2023Spec(), new CustomersWithLargeOrdersSpec());

public class OrdersWithDetailsSpec : Specification<Order>
{
    public OrdersWithDetailsSpec(DateTime start, DateTime end)
    {
        Query.Where(o => o.Created >= start && o.Created <= end)
             .Include(o => o.Items)
             .ThenInclude(i => i.Product)
             .OrderByDescending(o => o.Created)
             .TagWith("RangeQuery"); // استفاده از ویژگی TagWith
    }
}

// نمونه‌سازی یک شیء Specification
var spec = new PremiumCustomers2023Spec();

// تست منطق با یک شیء مشتری در حافظه
var customerInstance = new Customer { IsPremium = true, RegistrationYear = 2023, Name = "Alice" };
var isSatisfied = spec.IsSatisfiedBy(customerInstance); // این خط مقدار true را باز می‌گرداند.