يفصل CQRS، أي فصل مسؤولية الأوامر عن الاستعلامات، بين النموذج المستخدم لتحديث البيانات والنموذج المستخدم لقراءتها. يركز جانب الكتابة على قواعد الأعمال، بينما ينظّم جانب القراءة المعلومات للعرض أو البحث.
على سبيل المثال، يتطلب حجز تذكرة سينما التحقق من توافر المقعد. أما عرض قائمة التذاكر فيحتاج إلى اسم الفيلم وموعد العرض وموقع المقعد. تتعامل هذه المهام مع البيانات نفسها، لكنها تحتاج إلى معالجة مختلفة.
يمكن للنموذجين أن يوجدا في التطبيق نفسه وأن يشتركا في قاعدة بيانات. لا يشترط CQRS قاعدتي بيانات أو طابورًا أو اعتماد الأحداث مصدرًا للحالة.
عندما يختار العميل مقعدًا، يذهب الطلب إلى جانب الكتابة. يتحقق النظام من الحجز ويحفظه؛ ويجب أن تمنع معاملة ذات قيود بيانات مناسبة عميلين من حجز المقعد نفسه للعرض نفسه. بعد نجاح الكتابة، يتلقى العميل تأكيدًا.
عندما يفتح العميل «تذاكري»، يعيد جانب القراءة قائمة بأسماء الأفلام ومواعيد العرض والمقاعد. ويمكن تغيير طريقة عرضها دون تغيير قواعد الحجز.
إذا أصبحت الاستعلامات مكلفة، يمكن للنظام الاحتفاظ بجدول قراءة منفصل جُمعت فيه هذه التفاصيل مسبقًا. وإذا حُدّث ذلك الجدول بصورة غير متزامنة، فقد لا تظهر التذكرة الجديدة فورًا؛ لذلك ينبغي أن تحتفظ الواجهة بتأكيد نجاح الحجز أثناء تحديث القائمة.
يفيد CQRS عندما تتضمن التحديثات قواعد أعمال كثيرة، بينما تحتاج الشاشات أو التقارير إلى تمثيل مختلف جدًا. ويمكن تطبيقه على حجز التذاكر فقط بدلًا من النظام كله.
في التطبيقات التي تكتفي بإنشاء سجلات بسيطة وقراءتها وتحديثها وحذفها، غالبًا ما يكون تطوير نموذج مشترك واحد أسهل.
مكتبة من أسئلة مقابلات تقنية المعلومات مع إجابات مفصّلة — من المبتدئ إلى المتقدم.
تبرع