نموذج بياناتي كان يخدم القراءة والكتابة… وفشل في كليهما: كيف أنقذني نمط CQRS من هذا التعقيد القاتل؟

حكاية “المنتج الشامل” الذي كاد أن يغرق المشروع

يا جماعة الخير، اسمحوا لي أن أبدأ معكم بحكاية من أيام الشباب، قصة فيها عِبَر ودروس كلفتني ليالي طويلة من السهر أمام الشاشة. كنا نعمل على منصة تجارة إلكترونية طموحة، وفي قلب هذه المنصة كان هناك نموذج بيانات واحد اسمه `Product` (المنتج). في البداية، كان هذا النموذج بسيطًا وجميلًا، “زي الحلاوة”، فيه اسم المنتج وسعره ووصفه.

لكن مع تطور المشروع، بدأ هذا النموذج المسكين يتحمل أعباءً فوق طاقته. فريق التسويق أراد إضافة حقول للكلمات المفتاحية وتحسين محركات البحث (SEO). فريق المستودعات طلب حقولاً لتتبع المخزون والموردين وفروع التوفر. فريق تجربة المستخدم أراد نظام تقييمات معقد وحساب متوسط التقييمات بشكل فوري. أما نحن المبرمجين، فكنا نضيف حقولاً مؤقتة (flags) وحقولاً للعلاقات مع كل جدول جديد يخطر ببالنا.

تحول جدول `Products` في قاعدة البيانات إلى وحش كاسر. عمليات الكتابة (مثل تحديث سعر منتج) أصبحت بطيئة لأنها تحتاج إلى تحديث عشرات الفهارس (Indexes) وحساب حقول أخرى. وعمليات القراءة (مثل بحث المستخدم عن منتج مع فلترة حسب السعر والتقييم والتوفر) أصبحت كابوسًا من الاستعلامات المعقدة (Complex Joins) التي تستغرق ثوانٍ لتُنفذ.

وصلنا إلى مرحلة خطيرة: النموذج الواحد الذي كان من المفترض أن يخدم القراءة والكتابة، أصبح يفشل في كليهما. التحديثات تسبب “وجع راس” وتؤدي إلى قفل الجداول (Table Locks)، والبحث بطيء لدرجة أن المستخدم يمل ويغادر الموقع. في إحدى الليالي، وأنا أتأمل هذا التعقيد، قلت لنفسي: “أكيد في طريقة أحسن! مش معقول الشركات الكبيرة شغالة هيك!”. ومن هنا بدأت رحلتي مع منقذي: نمط CQRS.

المشكلة الكلاسيكية: نموذج واحد لكل المهام

القصة التي رويتها لكم ليست فريدة من نوعها، بل هي السيناريو الطبيعي لمعظم التطبيقات التي تبدأ بنمط CRUD التقليدي (Create, Read, Update, Delete). في هذا النمط، نستخدم نفس نموذج البيانات (Data Model) ونفس الكائن (Object) لجميع العمليات:

• عندما نريد إنشاء منتج جديد، نملأ كائن `Product` ونحفظه.
• عندما نريد عرض تفاصيل المنتج، نسترجع كائن `Product` من قاعدة البيانات.
• عندما نريد تحديث سعره، نسترجع كائن `Product`، نغير السعر، ثم نحفظه.

هذا النهج ممتاز للمشاريع البسيطة، لكنه يصبح عقبة عندما يكبر التطبيق. لماذا؟

لأن متطلبات القراءة ومتطلبات الكتابة غالبًا ما تكون متعارضة تمامًا. عملية الكتابة تهتم بصحة البيانات (Validation)، وتطبيق قواعد العمل (Business Logic)، والحفاظ على تناسق الحالة (Consistency). أما عملية القراءة، فكل همها هو السرعة وتقديم البيانات بالشكل الذي تحتاجه واجهة المستخدم بالضبط.

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

الحل السحري: CQRS – فصل السلطات البرمجية

هنا يأتي دور نمط CQRS (Command Query Responsibility Segregation)، أو “فصل مسؤولية الأوامر عن الاستعلامات”. الفكرة عبقرية في بساطتها: بدلًا من استخدام نموذج واحد، سنقوم بفصل التطبيق إلى مسارين منفصلين تمامًا:

1. مسار الأوامر (Commands): مسؤول فقط عن تغيير حالة النظام (إنشاء، تحديث، حذف). لا يُرجع أي بيانات.
2. مسار الاستعلامات (Queries): مسؤول فقط عن قراءة البيانات وتقديمها للعرض. لا يغير أي شيء في النظام.

تخيل الأمر كأنك في مطعم كبير. قسم المطبخ (مسار الأوامر) هو المكان الذي يتم فيه تحضير الطعام وتغيير حالة المكونات الخام إلى طبق جاهز. أما قسم تقديم الطعام في الصالة (مسار الاستعلامات)، فهو المسؤول عن عرض الطبق الجاهز للزبون بأجمل صورة ممكنة. القسمان يعملان معًا، لكن لكل منهما أدواته وعملياته المختلفة.

الجانب الأول: مسار الأوامر (The Write Side)

هذا الجانب هو “العقل المدبر” للنظام. نماذج البيانات هنا (تُعرف أحيانًا بالـ Domain Models أو Aggregates) تكون غنية بقواعد العمل والمنطق. هدفها هو حماية حالة النظام وضمان صحتها.

• التركيز: على التحقق من صحة المدخلات، تطبيق قواعد العمل المعقدة، وضمان أن كل تغيير يتم بشكل سليم.
• مثال: عند تحديث سعر منتج، نموذج الكتابة سيتأكد أن السعر لا يمكن أن يكون سالبًا، وأن المستخدم لديه الصلاحية للقيام بهذا التغيير، وقد يقوم بتسجيل هذا التغيير في سجل التدقيق (Audit Log).
• قاعدة البيانات: غالبًا ما تكون قاعدة بيانات علائقية مُصممة بشكل معياري (Normalized) لضمان تكامل البيانات.

هنا يكون الشغل “مرتب عالآخر”، كل شيء في مكانه وكل تغيير يتم حسب الأصول.

الجانب الثاني: مسار الاستعلامات (The Read Side)

هذا الجانب هو “الواجهة الإعلامية” السريعة. نماذج البيانات هنا (تُعرف بالـ Read Models أو DTOs) تكون بسيطة ومسطحة ومُصممة خصيصًا لتلبية احتياجات واجهة معينة.

• التركيز: على السرعة القصوى. لا يوجد أي منطق عمل هنا، مجرد قراءة مباشرة للبيانات.
• مثال: عندما يبحث المستخدم عن منتجات، نموذج القراءة سيكون جدولاً أو مستندًا (Document) يحتوي على كل ما تحتاجه صفحة النتائج في استعلام واحد بسيط: اسم المنتج، صورته، سعره، متوسط تقييمه، وحالة توفره. لا حاجة لعمليات `JOIN` معقدة.
• قاعدة البيانات: يمكن أن تكون أي شيء! قاعدة بيانات SQL غير معيارية (Denormalized)، قاعدة بيانات NoSQL مثل MongoDB أو Elasticsearch، أو حتى ذاكرة تخزين مؤقت (Cache) مثل Redis. نختار ما هو الأسرع والأفضل للمهمة.

مثال عملي: كيف يبدو CQRS في الكود؟

دعنا نأخذ مثال تحديث اسم منتج وعرضه. سأستخدم هنا كودًا شبيهًا بلغة C# لتوضيح الفكرة.

1. مسار الأوامر (The Command Stack)

القصة وما فيها تبدأ بـ “أمر” (Command). الأمر هو مجرد كائن بسيط يحمل النية والبيانات اللازمة للتغيير.

// Command: مجرد حامل بيانات بسيط
public class UpdateProductNameCommand
{
    public Guid ProductId { get; set; }
    public string NewName { get; set; }
    public string UserId { get; set; } // لمعرفة من قام بالتغيير
}

// Command Handler: هنا يكمن المنطق الحقيقي
public class UpdateProductNameCommandHandler
{
    private readonly IProductRepository _productRepository;

    public UpdateProductNameCommandHandler(IProductRepository productRepository)
    {
        _productRepository = productRepository;
    }

    public void Handle(UpdateProductNameCommand command)
    {
        // 1. استرجاع النموذج الغني من قاعدة بيانات الكتابة
        var product = _productRepository.FindById(command.ProductId);

        if (product == null)
        {
            throw new Exception("المنتج غير موجود!");
        }

        // 2. تطبيق منطق العمل (Business Logic)
        // يمكن أن يكون هذا المنطق داخل كائن المنتج نفسه (Domain Model)
        product.ChangeName(command.NewName, command.UserId);

        // 3. حفظ التغييرات في قاعدة بيانات الكتابة
        _productRepository.Save(product);
        
        // ملاحظة: هذا الـ Handler لا يُرجع أي بيانات!
    }
}

2. مسار الاستعلامات (The Query Stack)

عندما تريد واجهة المستخدم عرض بيانات المنتج، فإنها ترسل “استعلامًا” (Query).

// Query: يصف البيانات المطلوبة
public class GetProductDetailsQuery
{
    public Guid ProductId { get; set; }
}

// Read Model: كائن مسطح ومُحسَّن للعرض
public class ProductDetailsViewModel
{
    public Guid Id { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; }
    public double AverageRating { get; set; }
    public string ImageUrl { get; set; }
}

// Query Handler: يستعلم من قاعدة بيانات القراءة مباشرة
public class GetProductDetailsQueryHandler
{
    // يمكن أن تكون هذه قاعدة بيانات مختلفة تمامًا!
    private readonly IReadDatabaseConnection _readDb;

    public GetProductDetailsQueryHandler(IReadDatabaseConnection readDb)
    {
        _readDb = readDb;
    }

    public ProductDetailsViewModel Handle(GetProductDetailsQuery query)
    {
        // استعلام بسيط جداً ومباشر من جدول/مستند مُحسَّن للقراءة
        var sql = "SELECT Id, Name, Price, AverageRating, ImageUrl FROM ProductViewModels WHERE Id = @ProductId";
        var product = _readDb.QueryFirstOrDefault<ProductDetailsViewModel>(sql, new { query.ProductId });
        
        return product;
    }
}

3. الحلقة المفقودة: كيف تتم المزامنة؟

سؤال وجيه: إذا غيرنا البيانات في “جانب الكتابة”، كيف تصل هذه التغييرات إلى “جانب القراءة”؟

الجواب هو من خلال الأحداث (Events). عندما ينجح مسار الأوامر في تغيير شيء ما، فإنه ينشر “حدثًا” يصف ما حدث. على سبيل المثال، بعد تحديث اسم المنتج بنجاح، يقوم `UpdateProductNameCommandHandler` بنشر حدث اسمه `ProductNameUpdated`.

هناك مكون آخر في النظام (Subscriber) يستمع لهذه الأحداث. عندما يسمع حدث `ProductNameUpdated`، فإنه يقوم بتحديث نموذج القراءة (Read Model) في قاعدة بيانات القراءة. هذه العملية قد لا تكون فورية، وهذا ما يقودنا إلى مفهوم الاتساق النهائي (Eventual Consistency). هذا يعني أن نموذج القراءة قد يتأخر بضع أجزاء من الثانية عن نموذج الكتابة، وهو أمر مقبول تمامًا في معظم تطبيقات الويب.

مستوى إضافي للمحترفين: وما قصة الـ Event Sourcing؟

كثيرًا ما يُذكر نمط Event Sourcing (تحديد مصدر الحالة من الأحداث) مع CQRS، لكنهما شيئان مختلفان. باختصار شديد:

في الـ Event Sourcing، نحن لا نخزن الحالة النهائية للبيانات (مثل اسم المنتج الحالي). بدلًا من ذلك، نخزن كل الأحداث التي أدت إلى هذه الحالة بالترتيب (`ProductCreated`, `ProductNameUpdated`, `ProductPriceIncreased`, …إلخ). الأمر أشبه بامتلاك “دفتر حسابات الأيام الخوالي” الذي يسجل كل حركة تمت، بدلًا من مجرد معرفة الرصيد النهائي.

عندما نريد معرفة الحالة الحالية للمنتج، نقوم بإعادة تشغيل (Replay) كل أحداثه. هذا النمط قوي جدًا مع CQRS، لأنه يجعل بناء نماذج القراءة (Read Models) أمرًا سهلًا للغاية؛ فكل ما علينا فعله هو تشغيل الأحداث وتحديث نموذج القراءة بناءً عليها.

نصيحة من أبو عمر: متى تستخدم CQRS ومتى تبتعد عنه؟

يا جماعة، CQRS ليس حلاً لكل المشاكل. استخدامه في مشروع بسيط يشبه استخدام مدفع لقتل ذبابة. إنه يضيف درجة من التعقيد، لذا يجب استخدامه بحكمة.

استخدم CQRS عندما:

• لديك منطق عمل (Business Logic) معقد يطبق عند الكتابة.
• متطلبات القراءة والكتابة مختلفة جدًا وتسبب تعارضًا في الأداء.
• تحتاج إلى تحسين أداء القراءة بشكل كبير (High-performance read requirements).
• تعمل على أنظمة تعاونية (Collaborative Domains) حيث يقوم عدة مستخدمين بتعديل نفس البيانات.
• تتوقع أن ينمو نظامك بشكل كبير وتحتاج إلى قابلية التوسع (Scalability).

ابتعد عن CQRS عندما:

• مشروعك هو تطبيق CRUD بسيط.
• فريقك غير معتاد على هذه المفاهيم المتقدمة.
• تحتاج إلى اتساق فوري وقوي (Strong Consistency) بين عمليات القراءة والكتابة في كل أجزاء النظام.

نصيحة عملية: ليس عليك تطبيق CQRS على النظام بأكمله. يمكنك تطبيقه فقط على الأجزاء الأكثر تعقيدًا من تطبيقك (ما يسمى Bounded Context في تصميم DDD)، وترك الأجزاء البسيطة تعمل بنمط CRUD التقليدي. هذا هو جمال معمارية البرمجيات المرنة.

الخلاصة: استعادة السيطرة على التعقيد

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

تذكر دائمًا، CQRS ليس مجرد نمط تقني، بل هو طريقة تفكير. إنه يدور حول فهم أن المهام المختلفة تتطلب أدوات وحلولًا مختلفة. عندما تتوقف عن محاولة إجبار نموذج واحد على القيام بكل شيء، ستفتح الباب أمام تصميم أنظمة أكثر قوة ومرونة وقابلية للتطوير. لا تخف من فصل المسؤوليات، ففي الفصل تكمن القوة. 💪