تكرار السؤال: …
الإجابة المختصرة
بتقسيم الحل إلى 4 مشاريع: Domain (الكيانات ومنطق الأعمال النقي)، Application (حالات الاستخدام والواجهات)، Infrastructure (قواعد البيانات والـ APIs)، و WebApi (المتحكمات)، مع اتجاه التبعيات دائماً للداخل.
الشرح
الهدف الجوهري هو عزل منطق الأعمال الأساسي عن أي تفاصيل تقنية قابلة للتغيير. مشروع Domain لا يعتمد على أي مشروع آخر ولا يثبت أي حزم خارجية. مشروع Application يعرف حالات الاستخدام عبر MediatR Interfaces. بينما يعتمد مشروع Infrastructure على Application لتنفيذ الواجهات (مثل EF Core DbContext)، وتقوم طبقة WebApi بربط الجميع عبر الـ Dependency Injection.
مثال بالكود
// Shop.Domain (references nothing)
public class Order { public Guid Id { get; init; } public decimal Total { get; private set; } }
// Shop.Application → Domain
public interface IOrderRepository { Task<Order?> GetAsync(Guid id, CancellationToken ct); }
public class GetOrderHandler(IOrderRepository orders) { /* use case */ }
// Shop.Infrastructure → Application
public class EfOrderRepository(AppDbContext db) : IOrderRepository
{
public Task<Order?> GetAsync(Guid id, CancellationToken ct) => db.Orders.FindAsync([id], ct).AsTask();
}
// Shop.WebApi → Application + Infrastructure: the composition root connects the arrows
builder.Services.AddScoped<IOrderRepository, EfOrderRepository>();أخطاء شائعة
- إضافة مرجع لـ EF Core أو ASP.NET Core داخل مشروع Domain مما يلوث نقاء منطق الأعمال.