CQRS Architecture Pattern

المقدمة

بناء البرمجيات زي بناء المباني بالظبط محتاج ترتب أجزاء المبني وعلاقتهم ببعض بطريقة مناسبة لوظيفة المبني والمستخدمين, فالبيت مبني وكذلك الجامعة مبني ولكن الحجم, والوظيفة والمستخدمين مختلفين ومن هنا بتيجي فكرة ال Architectural Patterns في البرمجيات.

والشطارة بتكون في ازاي استخدم النمط الأكثر إفادة لوظيفة وحجم ونوع الاستخدام لمشروعي اللي شغال عليه.

Command Query Responsibility Segregation (CQRS)

في معظم مشاريعنا بنستخدم CRUD Pattern وبنعتمد علي الوظائف الأساسية فيه زي Create, Read, Update, Delete وبالفعل هو نمط مناسب للمشاريع البسيطة والصغيرة والمتوسطة في الحجم لأنه سهل.

ولكن في حالات بنحتاج فيها Data Manipulation اكثر من الـ CRUD يقدر يقدمه , زي اننا نشتغل في Business العلاقات فيه بين ال objects معقدة أكتر أو تطبيق يكون فيه استهلاك البيانات فيه عالي وكذلك كتابتها ودا بيوقعنا في مشكلة لأن متطلبات الـ Scaling في حالة الـ Heavy Reads تختلف عن متطلباته في حالة الـ Heavy Writes

ال CQRS اختصار لـ Command Query Responsibility Segregation أو Separation وهو نمط هدفه الفصل بين الـ Commands و الـ Queries في الكود وبنعّرف فيه:

الأوامر (Commands): : هي عملية كتابة أو تغيير البيانات وهي العمليات اللي فيها بتتغير حالة النظام. والأوامر جي بتقوم بـ "فعل" شيء وتؤثر على حالة النظام.
الاستعلامات (Queries): عملية قراءة البيانات وهي العمليات اللي بتسترجع بيانات و لكن لا تغير حالة النظام. بمعنى أنها "تسأل" عن شيء معين ولا تعدل أي شيء.

الـ CQRS يستخدم اثنين من الـ Models المختلفة عشان يحقق الأوامر (Commands) بالـ Model المناسب ليها و كذلك Model خاص بالـ للاستعلامات (Queries). وبما إن دا Architectural Pattern فبيسيب للمبرمج حرية اختيار وتنويع الـ Models اللي شايفها بتحقيق الهدفين دول وايه الأنسب لمشروعه وده بيدينا مرونة في التنفيذ.

كمان نقدر في تنفيذه نستخدم 2 من قواعد البيانات -الطريقة الأكثر شيوعًا- واحدة مخصصة للاستعلامات وواحدة للأوامر ويتعمل بينهم Synching.

مميزات الـ CQRS

فصل المسؤوليات بيساعد في إدارة الـ Business Logic المعقد ويساعد على سهولة صيانة الكود.
يسمح لنا بمرونة أكتر من ناحية الـ Scaling لو الأحمال الخاصة بالقراءة والكتابة في قواعد البيانات مختلفة ، فاقدر اشتغل على الـ Scaling الخاص بكل واحدة بالشكل اللي يناسبها.
يساعد جدًا في اختبار الكود, ودا لأني بسّطت أجزاء الكود المنفصلة.
بيزود الأمان لأننا كدا خلينا Model واحد هو المسؤول عن عملية تغيير البيانات وبكذا نضمن ان مفيش classes غير مسموح لها بتعديل البيانات بتغييرها.

عيوب الـ CQRS

بيزيد من تعقيد الكود لأنك بتستخدم أكثر من Model وكذلك عدد Methods أكبر.
لو استخدمنا في تطبيقه قاعدتين بيانات منفصلين فدا بيعرضنا لمشاكل ال Synchronization بين قاعدتين البيانات زي ال Data Consistency أو الـ Time Delay of Synchronization.

امتي استخدم ال CQRS

في حالة إن المشروع اللي شغالين عليه Data Intensive وفيه تباين كبير بين أحمال ال Reads مختلفة عن أحمال الـ Writes فهنضطر نعمل scale ليهم بشكل منفصل.
وجود Business Logic معقد بيحتاج فريق كامل يهتم بقراءة البيانات واخر بعملية تغيير البيانات.

💡

تطبيق الـ CQRS ممكن يبقى غير ضروري أو مبالغ فيه في الأنظمة الصغيرة أو البسيطة. وبالتالي استخدامه في الحالات دي قد يؤدي إلى زيادة في التعقيد بدون فائدة فعلية واضحة.