كان منطق أعمالنا ضائعاً بين طبقات الكود: كيف أنقذنا ‘التصميم الموجه بالمجال’ (DDD) من جحيم الفوضى؟

يا جماعة الخير، السلام عليكم ورحمة الله وبركاته. معكم أخوكم أبو عمر.

قبل كم سنة، كنا شغالين على مشروع كبير، منصة تجارة إلكترونية طموحة أسميناها “سوقنا”. البداية كانت حماسية، والكل شادد حيله. كتبنا الكود بسرعة، وضفنا الميزات وحدة ورا الثانية. العميل كان مبسوط، والإدارة كانت مبسوطة، وإحنا كنا حاسين حالنا “أبو العُرّيف” في البرمجة.

لكن بعد حوالي سنة، بدأت الكوابيس. كل ما نيجي نعدّل على شغلة بسيطة، تنضرب عشر شغلات ثانية ما إلها علاقة. طلب تعديل صغير على حساب سعر الشحن كان ياخذ أسبوعين بدل ساعتين! ليش؟ لأن منطق حساب السعر كان موزع في كل مكان: شوي في كود الواجهة الأمامية (Front-end)، وشوي في الـ Controller، وشوي في استعلام SQL معقد، وشوي مخبى في دالة غامضة ما حدا عارف شو بتعمل.

وصلنا لمرحلة إنه الفريق صار يخاف يلمس الكود. صرنا نحكي بين بعض: “يا زلمة هادا الكود زي حقل الألغام، دعسة غلط بتروح فيها”. منطق العمل (Business Logic)، اللي هو روح المشروع وأهم أشي فيه، كان ضايع ومتفتت بين طبقات الكود. في اجتماع من اجتماعات العصف الذهني اليائسة، واحد من الشباب، الله يجزيه الخير، رمى كلمة غيرت كل اشي: “يا جماعة، إحنا مشكلتنا مش في الكود، مشكلتنا إنه الكود ما بحكي لغة البزنس. سمعتوا عن إشي اسمه Domain-Driven Design؟”.

هون كانت بداية رحلة الإنقاذ. رحلة طويلة وصعبة، بس نتيجتها كانت تستاهل كل دقيقة تعب. اليوم، بدي أشارككم شو تعلمنا، وكيف الـ DDD أنقذنا من جحيم الفوضى.

ما هو “التصميم الموجه بالمجال” (DDD)؟ وليش لازم نهتم؟

ببساطة شديدة، الـ DDD هو منهجية في تصميم البرمجيات بتخلي “مجال العمل” (Domain) هو محور كل شيء. بدل ما نبدأ نفكر في قواعد البيانات والجداول والشاشات، الـ DDD بحكيلك: اهدأ، وروق، وفكّر أولاً في البزنس نفسه. شو العمليات الأساسية؟ شو القواعد اللي بتحكمها؟ شو المصطلحات اللي بستخدموها خبراء المجال (Domain Experts)؟

الهدف هو بناء “موديل” برمجي يعكس واقع البزنس بأكبر قدر ممكن من الدقة. لما الكود تبعك يصير يحكي نفس لغة خبراء البزنس، بتصير المعجزات. بصير التعديل أسهل، والتطوير أسرع، والأخطاء أقل.

اللغة الموحدة (Ubiquitous Language): حجر الزاوية

أول وأهم مفهوم في الـ DDD هو “اللغة الموحدة”. الفكرة عبقرية في بساطتها: لازم يكون في لغة مشتركة وموحدة بين كل الأطراف المعنية بالمشروع: المبرمجين، مدراء المنتجات، خبراء البزنس، وحتى العميل.

في مشروعنا “سوقنا”، كان في مصطلحات كثيرة لنفس الشيء. فريق البزنس بحكي “طلب شراء”، وفريق المستودع بحكي “أوردر”، والمبرمجين مسميين الجدول في قاعدة البيانات `customer_carts`. هاي الفوضى في المصطلحات بتترجم مباشرة لفوضى في الكود.

مع الـ DDD، جلسنا كلنا على طاولة واحدة وقررنا: الكلمة الرسمية هي “طلب” (Order). من هاي اللحظة، صار اسم الكلاس في الكود `Order`، واسم الجدول `Orders`، وفي اجتماعاتنا بنحكي “طلب”، وفي الواجهات بنكتب “تفاصيل الطلب”. هاي الوحدة في اللغة بتمنع سوء الفهم وبتخلي الكود مقروء ومفهوم للجميع.

السياق المحدود (Bounded Context): لكل مقامٍ مقال

هاي النقطة اللي عملت “كليك” في راسي. مش كل أجزاء النظام بتهتم بنفس التفاصيل. كلمة “منتج” (Product) معناها بيختلف من قسم لقسم.

• في سياق “المخزون” (Inventory Context): المنتج هو عبارة عن SKU، كمية متوفرة، موقع في المستودع.
• في سياق “المبيعات” (Sales Context): المنتج هو عبارة عن اسم، وصف، صور، وسعر.
• في سياق “الشحن” (Shipping Context): المنتج هو عبارة عن وزن، أبعاد، وهل هو قابل للكسر أم لا.

الـ DDD بحكيلك: لا تحاول تعمل كلاس `Product` واحد عملاق يخدم كل هاي الاحتياجات. هاد الطريق السريع للفوضى. بدلًا من ذلك، قسّم نظامك إلى “سياقات محدودة”. كل سياق له الموديل الخاص فيه، ولغته الموحدة الخاصة فيه. داخل سياق المبيعات، كلاس `Product` بيحتوي على السعر. داخل سياق الشحن، كلاس `Product` بيحتوي على الوزن. وهما مش نفس الكلاس!

هذا المفهوم هو الأساس اللي انبنت عليه معماريات حديثة مثل الخدمات المصغرة (Microservices)، حيث كل خدمة بتمثل غالبًا سياقًا محدودًا.

اللبنات الأساسية في كود DDD (The Building Blocks)

طيب يا أبو عمر، حكيت كتير تنظير، ورجينا شغل عملي. تكرم عينك. الـ DDD بيعطينا مجموعة من الأدوات أو “اللبنات” البرمجية عشان نبني الموديل تبعنا بشكل مرتب. خلينا نشوف أهمها بمثال من مشروع “سوقنا”.

الكيانات (Entities)

الكيان هو أي كائن في النظام له هوية فريدة ومستمرة عبر الزمن. أهم شي فيه هو الـ ID تبعه، مش خصائصه. “الطلب” (Order) هو كيان، لأنه حتى لو تغيرت حالته من “قيد التنفيذ” إلى “تم الشحن”، هو بضل نفس الطلب صاحب الرقم 12345.

// C# Example
public class Order : IEntity
{
    public Guid Id { get; private set; } // الهوية الفريدة
    public List Items { get; private set; }
    public OrderStatus Status { get; private set; }
    public Address ShippingAddress { get; private set; }

    // ... منطق الأعمال موجود هنا
    public void AddItem(Product product, int quantity)
    {
        if (Status != OrderStatus.Pending)
        {
            throw new InvalidOperationException("لا يمكن إضافة منتجات لطلب غير معلق");
        }
        // ... المزيد من القواعد
        Items.Add(new OrderItem(product.Id, quantity, product.Price));
    }

    public void Ship()
    {
        if (Status != OrderStatus.Paid)
        {
            throw new InvalidOperationException("لا يمكن شحن طلب غير مدفوع");
        }
        Status = OrderStatus.Shipped;
    }
}

لاحظ كيف أن منطق العمل (مثل عدم السماح بإضافة منتج لطلب تم شحنه) موجود داخل الكيان نفسه. هذا هو قلب الـ DDD: الكائنات ذكية وتحمي حالتها بنفسها.

كائنات القيمة (Value Objects)

على عكس الكيانات، كائنات القيمة ليس لها هوية. هي تُعرَّف بقيمتها فقط. أفضل مثال هو “العنوان” (Address) أو “المال” (Money). عنوانين متطابقين (نفس الشارع، نفس المدينة، نفس الدولة) هما نفس العنوان. ما بهمني الـ ID تبعهم.

كائنات القيمة لازم تكون غير قابلة للتغيير (Immutable). إذا بدك تغير العنوان، أنت بتنشئ كائن عنوان جديد، ما بتعدل على القديم.

// C# Example
public class Money : ValueObject
{
    public decimal Amount { get; private set; }
    public string Currency { get; private set; }

    public Money(decimal amount, string currency)
    {
        // ... Add validation rules
        Amount = amount;
        Currency = currency;
    }

    // لا يمكن تغيير القيمة بعد الإنشاء (Immutable)
    // للمقارنة، نقارن القيم وليس المرجع في الذاكرة
}

استخدام `Money` ككائن قيمة بدلًا من مجرد `decimal` بيحمينا من أخطاء كثيرة، مثل جمع مبالغ بعملات مختلفة بالخطأ.

التجميعات (Aggregates) وجذر التجميع (Aggregate Root)

هذا المفهوم شوي متقدم لكنه محوري. التجميعة هي مجموعة من الكيانات وكائنات القيمة اللي بتتعامل معها كوحدة واحدة متكاملة. ولكل تجميعة “جذر” (Aggregate Root) هو الكيان الرئيسي اللي بمثل البوابة الوحيدة للتفاعل مع هاي التجميعة.

قاعدة مهمة: أي تعامل مع أي جزء من التجميعة يجب أن يمر حصرًا من خلال جذر التجميعة.

في مثالنا، “الطلب” (`Order`) هو جذر التجميعة. التجميعة نفسها تحتوي على `Order` و `OrderItem`. لا يجوز لك برمجيًا أن تصل إلى `OrderItem` مباشرة من خارج التجميعة وتعدل عليها. لازم تطلب من كائن الـ `Order` إنه يضيف أو يعدل `OrderItem` بالنيابة عنك عبر استدعاء دالة مثل `order.AddItem()`.

ليش؟ لأن جذر التجميعة هو حارس البوابة. هو المسؤول عن تطبيق كل قواعد البزنس (Invariants) وضمان بقاء التجميعة في حالة صحيحة ومتناسقة. مثلا، هو بيضمن إنه مجموع أسعار الـ `OrderItem`s يطابق السعر الإجمالي للـ `Order`.

المستودعات (Repositories)

المستودع هو مجرد واجهة برمجية (Interface) بتفصل بين منطق العمل (Domain Model) وطريقة تخزين البيانات (Persistence). كود البزنس تبعك ما لازم يعرف هل انت بتستخدم SQL Server ولا MongoDB ولا بتخزن البيانات في ملف نصي.

// C# Example
public interface IOrderRepository
{
    Task<Order> GetByIdAsync(Guid orderId);
    Task SaveAsync(Order order);
}

// كود منطق التطبيق (Application Logic)
public class OrderService
{
    private readonly IOrderRepository _orderRepository;

    public OrderService(IOrderRepository orderRepository)
    {
        _orderRepository = orderRepository;
    }

    public async Task AddProductToOrder(Guid orderId, Product product, int quantity)
    {
        var order = await _orderRepository.GetByIdAsync(orderId);
        order.AddItem(product, quantity); // منطق العمل يتم في الـ Domain
        await _orderRepository.SaveAsync(order); // المستودع يحفظ التغييرات
    }
}

لاحظ كيف أن `OrderService` لا يعرف أي شيء عن قاعدة البيانات. هو فقط يتعامل مع `IOrderRepository`.

نصائح من قلب المعركة: كيف تطبق DDD بنجاح؟

التحول للـ DDD مش كبسة زر. هو تغيير في طريقة التفكير. من تجربتي، هاي شوية نصائح ممكن تساعدكم:

• ابدأ صغيرًا: لا تحاول إعادة كتابة كل النظام دفعة واحدة. اختار “سياق محدود” (Bounded Context) واحد يكون مهم ومعقد، وابدأ بتطبيق مفاهيم الـ DDD عليه.
• تحدث، ثم تحدث، ثم تحدث: أهم أداة عندك هي الحوار مع خبراء المجال. اجلس معهم، افهم مصطلحاتهم، مشاكلهم، وطريقة تفكيرهم. “اللغة الموحدة” تولد من هذه الجلسات.
• ليس كل المشاريع تحتاج DDD: إذا كنت تبني مدونة بسيطة أو تطبيق CRUD (Create, Read, Update, Delete) مباشر، فالـ DDD قد يكون تعقيدًا زائدًا (Over-engineering). الـ DDD يلمع نجمه في الأنظمة المعقدة ذات منطق العمل الغني.
• الصبر يا جماعة: النتائج لن تظهر بين ليلة وضحاها. ستحتاج وقتًا لتدريب الفريق وتغيير العقلية. لكن صدقني، الاستثمار هذا سيعود عليك بأضعاف في المستقبل على شكل نظام قابل للصيانة والتطوير.
• ارسم الخرائط: استخدم تقنيات مثل “Event Storming” أو “Context Mapping” عشان ترسم خريطة لمجال العمل وتحدد السياقات المحدودة والعلاقات بينها. الرؤية الواضحة هي نصف الحل.

الخلاصة: من الفوضى إلى النظام 🚀

في النهاية، التصميم الموجه بالمجال ليس مجرد مجموعة من الأنماط البرمجية، بل هو فلسفة تهدف إلى تقريب المسافة بين لغة الآلة ولغة البشر. هو استثمار في فهم “جوهر” المشكلة التي نحاول حلها، بدلًا من القفز مباشرة إلى الحلول التقنية.

رحلتنا مع مشروع “سوقنا” كانت صعبة، ولكن بفضل الـ DDD، استطعنا تحويل الكود من “حقل ألغام” إلى “شغل مرتب” ومنظم، يعكس منطق العمل الحقيقي. صار كل عضو جديد في الفريق قادر على فهم الكود بشكل أسرع، وصارت عملية إضافة الميزات الجديدة ممتعة بدلًا من كونها مرعبة.

نصيحتي الأخيرة لكل مبرمج ومطور: لا تجعل منطق عملك يضيع بين طبقات الكود. أعطه المكانة التي يستحقها في قلب تصميمك. تعلم عن الـ DDD، طبقه بحكمة، وشاهد كيف تتحول الفوضى إلى نظام وإبداع. والله ولي التوفيق.