SOLID و Architecture

#S: Single Responsibility و CohesionS: single responsibility and cohesion

لو تغيير شكل الإيميل بيخلّيك تلمس حساب الفاتورة، المسؤوليات متلخبطة. SRP بتجمع الكود اللي بيتغير لنفس السبب وتفصل اللي بيتغير لأسباب مختلفة؛ مش معناها method واحدة لكل class. Cohesion ترابط مسؤوليات الوحدة من جوه؛ coupling اعتمادها على وحدات تانية. عايزين cohesion عالية واعتمادات قليلة وواضحة.

public sealed class InvoiceService
{
    public string BuildEmail(decimal subtotal) =>
        $"<p>Total: {subtotal * 1.14m}</p>";
}

public sealed class InvoiceTotals(decimal taxRate)
{
    public decimal Calculate(decimal subtotal) => subtotal * (1 + taxRate); // (1)
}
public sealed class InvoiceEmail
{
    public string Format(decimal total) => $"Total: {total:0.00}";          // (2)
}

اختبار القواعد بقى من غير email server. لكن ماتقسمش كل سطر في class؛ لو التغيير دايمًا بيحصل مع بعض، الفصل الزيادة بيصعّب تتبع التدفق.

#O: Open/Closed عند نقطة التغييرO: open/closed at a real variation point

لو كل طريقة خصم جديدة بتعدّل نفس switch كبيرة، عندك نقطة تغيير متكررة. OCP بتخلي إضافة نوع جديد تتم بimplementation جديدة للعقد المستقر. مش معناها إن الكود ممنوع يتعدل؛ اكتشاف bug أو تغيير العقد يستلزم تعديل واختبار.

decimal Discount(decimal total, string kind) => kind switch
{
    "percent" => total * 0.1m,
    "fixed" => Math.Min(total, 50m),
    _ => throw new ArgumentException("Unknown discount")
};

public interface IDiscountRule { decimal Calculate(decimal total); } // (1)
public sealed class PercentDiscount(decimal rate) : IDiscountRule
{
    public decimal Calculate(decimal total) => total * rate;
}
public sealed class DiscountCalculator(IDiscountRule rule)
{
    public decimal Calculate(decimal total) => rule.Calculate(total); // (2)
}

Strategy وDI أدوات تطبيق. switch صغيرة على حالات ثابتة ومغلقة ممكن تبقى أوضح من عشر interfaces. ماتعملش extension point لمجرد احتمال بعيد.

#L: Liskov و Rectangle/SquareL: Liskov and rectangle/square

الوراثة وعد سلوكي: subtype لازم تشتغل مكان base من غير ما تكسر توقعات العميل. ممنوع تقوّي preconditions أو تضعّف postconditions اللي العقد وعد بيها. المربع مستطيل رياضيًا، لكن مش مستطيل mutable بيقبل تغيير العرض والطول بشكل مستقل.

public class Rectangle
{
    public virtual int Width { get; set; }
    public virtual int Height { get; set; }
}
public sealed class Square : Rectangle
{
    public override int Width
    {
        get => base.Width;
        set { base.Width = value; base.Height = value; }
    }
    public override int Height
    {
        get => base.Height;
        set { base.Width = value; base.Height = value; }
    }
}
// For a Rectangle, the client expects 5 * 10 = 50.
Rectangle shape = new Square();
shape.Width = 5;
shape.Height = 10;                     // Width also becomes 10; area = 100

public interface IShape { int Area { get; } }                  // (1)
public sealed record Rectangle(int Width, int Height) : IShape
{
    public int Area => Width * Height;
}
public sealed record Square(int Side) : IShape
{
    public int Area => Side * Side;                            // (2)
}

دي بدائل مستقلة، مش تعريفات تتجمع في نفس الملف. ماتحكمش على LSP بمجرد وجود exception؛ السؤال هل الـ exception أو السلوك خالفوا العقد؟

#I: Interface Segregation بالـ capabilitiesI: interface segregation through capabilities

الـ interface عقد صغير بيقول للعميل يقدر يطلب إيه من object. لو عقد الدفع وعد إن كل مزود يقدر يعمل refund، هيبقى وعد كاذب لمزود كاش مايعرفش يرجّع عملية إلكترونية. ISP بتقسم العقود حسب القدرة اللي العميل محتاجها فعلاً، مش حسب عدد methods ثابت.

public interface IPaymentProvider
{
    Task ChargeAsync(decimal amount);
    Task RefundAsync(string paymentId);
}
public sealed class CashProvider : IPaymentProvider
{
    public Task ChargeAsync(decimal amount) => Task.CompletedTask;
    public Task RefundAsync(string paymentId) => throw new NotSupportedException();
}

public interface IChargeProvider
{
    Task ChargeAsync(decimal amount, CancellationToken ct);
}
public interface IRefundProvider
{
    Task RefundAsync(string paymentId, CancellationToken ct);        // (1)
}
public sealed class RefundPayment(IRefundProvider refunds)
{
    public Task Run(string paymentId, CancellationToken ct) =>
        refunds.RefundAsync(paymentId, ct);                         // (2)
}

الكود الغلط mock لسلوك مش مكتمل، مش تنفيذ دفع حقيقي. ممكن provider تنفذ العقدين؛ مش لازم تفصلها في objectين. لو العقود بتتغير مع بعض ونفس العملاء محتاجينها، تقسيمها الزيادة بيزود الضوضاء.

#D: Dependency Inversion مش مجرد InjectionD: dependency inversion is more than injection

في تأكيد order، policy هي قاعدة التطبيق: إيه اللي يحصل بعد التأكيد؟ Infrastructure هي تفاصيل الوسيلة، زي الكتابة لملف أو استخدام SDK خارجي. لو checkout اختار الوسيلة بنفسه، تغيير التخزين يجرّ تعديل قاعدة العمل. Abstraction هنا contract صغير يصف احتياج checkout من غير ما يحدد الوسيلة. مبدأ DIP بيخلّي قاعدة العمل تعتمد على الـ contract، والوسيلة تنفذه. Dependency injection (DI) طريقة توصيل التنفيذ من بره؛ حقن class ملموسة مباشرة لوحده مش DIP.

public sealed class ConfirmOrder
{
    public void Run(int id) =>
        File.AppendAllText("orders.log", $"Confirmed {id}\n");
}

// Application project
public interface IOrderNotifications { void Confirmed(int orderId); } // (1)
public sealed class ConfirmOrder(IOrderNotifications notifications)
{
    public void Run(int id) => notifications.Confirmed(id);
}
// Infrastructure project references Application.
public sealed class FileOrderNotifications(string path) : IOrderNotifications
{
    public void Confirmed(int id) =>
        File.AppendAllText(path, $"Confirmed {id}\n");                // (2)
}
// Composition root supplies path and implementation.                 // (3)

المثال لتوضيح اتجاه الاعتماد، مش ضمان durable notification. ما تعملش interface لكل utility خالصة؛ اعزل الحدود اللي لها سبب حقيقي للتغيير أو الاختبار.

#Layered و Clean و Hexagonal و Onion و Vertical SlicesLayered, Clean, Hexagonal, Onion and vertical slices

إضافة feature بتحتاج رحلة في عشر فولدرات؟ أو domain rules مربوطة بـ HTTP؟ اختار التنظيم حسب المشكلة. الأسماء دي متداخلة، ومش frameworks لازم تختار واحدة بس منها.

Clean source references:
Shop.Application → Shop.Domain                          (1)
Shop.Infrastructure → Shop.Application, Shop.Domain
Shop.Api → Shop.Application, Shop.Infrastructure         (2)

Inside Application, organized by feature:
Features/Orders/PlaceOrder/Handler.cs                     (3)
Features/Orders/GetSummary/Handler.cs

تبديل database مش بالضرورة تعديل ملف واحد؛ transactions وSQL semantics ممكن تتسرب. الفايدة الأساسية حدود واعتمادات واضحة. CRUD صغير ممكن يحتاج slices بسيطة بس. Microsoft architecture guide.

#DDD strategic: حدود المعنىStrategic DDD: boundaries of meaning

كلمة Product عند فريق catalog معناها اسم وصور، وعند inventory معناها رصيد وموقع تخزين. إجبار الاتنين على giant model بيخلق coupling. Bounded context حدود model ومعنى المصطلحات، وubiquitous language نفس اللغة اللي الخبراء والكود بيستخدموها.

Context map بتسجل علاقة الـ contexts: مين upstream، ومين downstream، ومين مالك العقد، وهل فيه published language أو anti-corruption layer للترجمة. Context مش لازم microservice، ومش لازم يطابق جدول أو فريق بالظبط.

Catalog [upstream] -- ProductSnapshot v1 --> Sales [downstream]   (1)
Payment provider -- external status --> ACL --> Sales.PaymentState (2)
Inventory owns availability; Catalog owns descriptions.          (3)

ابدأ بحوارات وأمثلة مع business experts. DDD مش مسابقة أسماء classes؛ لو المجال بسيط وثابت، tactical patterns كتير ممكن ماتستاهلش تكلفتها.

#DDD tactical: حماية الـ invariantsTactical DDD: protecting invariants

لو كل controller بتقرر لوحدها هل order مدفوعة ينفع تتعدل، القاعدة هتختلف. Entity ليها هوية ثابتة، وvalue object بتتقارن بقيمتها. Aggregate حدود consistency ليها root تتحكم في التعديل؛ مش object graph تضم كل حاجة مرتبطة بforeign key.

public sealed record OrderLine(Guid ProductId, int Quantity);
public sealed record OrderConfirmed(Guid OrderId);
public sealed class Order
{
    private readonly List<OrderLine> _lines = [];
    private readonly List<OrderConfirmed> _events = [];
    public Guid Id { get; } = Guid.CreateVersion7();
    public bool IsConfirmed { get; private set; }
    public IReadOnlyList<OrderLine> Lines => _lines.AsReadOnly(); // (1)
    public IReadOnlyList<OrderConfirmed> Events => _events.AsReadOnly();
    public void AddLine(Guid productId, int quantity)
    {
        if (IsConfirmed) throw new InvalidOperationException("Order locked");
        ArgumentOutOfRangeException.ThrowIfNegativeOrZero(quantity);
        _lines.Add(new(productId, quantity));                    // (2)
    }
    public void Confirm()
    {
        if (IsConfirmed) return;
        if (_lines.Count == 0) throw new InvalidOperationException("Empty order");
        IsConfirmed = true;
        _events.Add(new(Id));                                    // (3)
    }
}

المثال model صغير؛ التطبيق لازم يوصل exceptions المتوقعة لنتيجة واضحة، ويحمي التزامن في database. Encapsulation وحدها مش بتمنع concurrent updates. ماتحمّلش ملايين السطور في aggregate واحدة؛ اختار boundaries على أساس invariants.

#Modular monolith: حدود من غير شبكةModular monolith: boundaries without a network

لو الفريق محتاج فصل ملكية features لكن مش محتاج deploy مستقل، modular monolith بداية عملية: executable واحدة، modules بعقود معلنة وimplementation مخفية. فصل الفولدرات بس مش modularity لو كل واحد بيقرأ جداول التاني.

Shop.Catalog.Contracts     ICatalogPrices, ProductPriceDto       (1)
Shop.Catalog               internal entities and persistence
Shop.Sales.Contracts       PlaceOrderRequest, OrderSummary
Shop.Sales                 references Catalog.Contracts only     (2)
Shop.Host                  registers module implementations      (3)

نفس database ممكنة مع schemas وملكية واضحة. transaction مشتركة بين modules قرار مقصود يزيد coupling، ومش تلقائية لو كل module ليها DbContext. التوسع والنشر غالبًا للتطبيق كله. استخراج module لخدمة بعدين أسهل بحدود جيدة، لكنه لسه محتاج data migration ومعالجة network failures.

#Microservices: الاستقلال له تمنMicroservices: independence has a cost

لو جزء محتاج scaling أو release cadence أو ownership مستقلين، خدمة منفصلة ممكن تستاهل. لكن network call مش method call: latency وpartial failure وtimeouts وversioning جزء من التصميم.

API gateway routing وسياسات عامة، وBFF backend مخصوص لاحتياج client زي mobile. الاتنين مايتحولوش لمكان كل domain logic. Service discovery تربط اسم منطقي بعنوان instance؛ ممكن DNS أو registry أو platform routing.

Mobile → Mobile BFF → Sales API → Sales-owned database         (1)
                              → outbox → broker → Inventory   (2)
Old application → routing boundary → extracted Catalog API     (3)

مش كل bounded context محتاجة service، ومش كل async communication broker. ابدأ بأقل deployment complexity تحقق المتطلبات، وراجع توزيع transactions قبل التقسيم.

#CQRS: افصل احتياجات القراءة والكتابةCQRS: separate read and write needs

تأكيد order محتاج invariants، لكن عرض summary محتاج projection خفيفة. CQRS تفصل models ومسارات commands عن queries. «Light» هنا نفس database، و«full» shorthand لنموذج فيه read store منفصلة؛ دي تسميات شائعة مش درجات رسمية. Event sourcing مش شرط.

// Application fragments; db exposes EF-mapped Orders.
public sealed record ConfirmOrder(int Id);
public sealed record OrderSummary(int Id, string Status);

// Command handler: load, enforce domain behavior, persist.
var order = await db.Orders.SingleAsync(o => o.Id == command.Id, ct);
order.Confirm();
await db.SaveChangesAsync(ct);                               // (1)

// Query handler: project directly, without loading the aggregate.
var summary = await db.Orders.AsNoTracking()
    .Where(o => o.Id == id)
    .Select(o => new OrderSummary(o.Id, o.Status))
    .SingleOrDefaultAsync(ct);                               // (2)

MediatR اختيار implementation مش CQRS نفسها، وملكية licensing تتراجع قبل الاعتماد. لمشروع CRUD بسيط فصل handlers شكليًا ممكن مايضيفش قيمة.

#ADRs و Architecture testsADRs and architecture tests

رسم الحدود من غير سبب موثّق أو فحص آلي بيتنسي مع الوقت. ADR سجل قرار واحد: context، والبدائل، والقرار، والنتائج، والحالة. ماتكتبش documentation بتقول كل اختيار ممتاز؛ سجّل التمن وامتى تعيد النظر.

ADR 004: Keep checkout in the modular monolith              (1)
Status: Accepted
Context: Stock reservation and order creation need one local commit.
Alternatives: Shared transaction; service split with saga.
Decision: Shared transaction with explicit module participation.
Consequence: More coupling; simpler atomic persistence.
Revisit: Inventory requires independent ownership or deployment.

// Test project: NetArchTest.Rules and the chosen xUnit package.
using NetArchTest.Rules;
using Xunit;

public sealed class BoundaryTests
{
    [Fact]
    public void Domain_does_not_depend_on_infrastructure()
    {
        var assembly = typeof(Shop.Domain.Order).Assembly;          // (2)
        var result = Types.InAssembly(assembly)
            .ShouldNot().HaveDependencyOn("Shop.Infrastructure")
            .GetResult();
        Assert.True(result.IsSuccessful);                          // (3)
    }
}

NetArchTest وArchUnitNET أدوات لكتابة قواعد اعتماد؛ ماتثبتش domain correctness أو تمنع SQL خام من تجاوز ملكية البيانات. لو بتسمح بـ Catalog.Contracts، ماتمنعش namespace prefix تشملها بالغلط؛ افصل implementation namespaces أو حدد المجموعة بدقة.