في هذه الصفحة
المقدمة
في هذا المقال هنتكلم عن الـ CQRS and Mediator pattern وايه علاقتهم ببعض وليه بنستخدمهم.
ال CQRS هو عبارة عن architectural pattern بيستخدم عشان يفصل عمليات ال read عن عمليات ال write وهو اختصار ل Command and Query Responsibility Segregation.
و Segregation ياعزيزي = separation of concern الاتنين نفس المعني يعني هنا نقدر نقول ان ال CQRS بي separate the concerns of reading and writing data وهنشرح الكلام ده بالتفصيل.
ليه نستعمل الـ CQRS ؟
ليه إحنا عاوزين نفصل عمليات ال Read عن ال write , يعني ليه اخترعوا لنا ال CQRS ؟
زي مانت عارف اي Pattern بيطلع عشان يحل مشكلة ما شائعه واجهتنا كلنا ومشكلتنا النهاردة هي ان في معظم ال apps بيكون في عمليات كتير جدا read و write ولما عدد المستخدمين لل app بيزيد ده هتلاقي المشاكل تبدأ تظهر على مستوى :
- الـ Performance : علمليات ال read ليها خصائص وسمات مختلفه عن ال write عشان تعطي افضل performance وبالتالي عشان انت ت manage الاتنين في نفس ال model ممكن يؤدي الى اداء دون المستوى وده لانك هتلاقي في سوء استخدام لل resources او ال resources مش allocated efficiently بناء على احتياجات كل operation .
- الـ Scalability : بيكون في تناقض بين عمليات ال read وعمليات ال write في ال app . في جزء من ال app بي handle جزء كبير من عمليات ال read وجزء تاني بي handle عدد كبير من عمليات ال write وفي الحالة دي ممكن يكون انك ت scale ال app عشان يقدر handle النوعين دول من العمليات بشكل متساوي هيكون الموضوع غير فعال ومكلف .
هتسألني ليه هيكون الموضع غير فعال ومكلف ؟
طبعا في اسباب كتير لكن انا هكتفي بسبب واحد وهو المتطلبات المختلفة لل Resource بين Reads و Writes Different Resource Requirements for Reads and Writes:
بالنسبة لعمليات الـ READ: عمليات القراءة غالبًا بتكون أقل استهلاكًا للموارد مقارنة بالكتابة. يعني لما تقرأ بيانات من قاعدة البيانات، بيكون في الغالب بيتم استرجاع البيانات من الكاش أو من نسخة مكررة في النظام، وده بيخلي عملية القراءة أسرع وأسهل لتوزيعها على عدة خوادم. عشان كده، لو التطبيق بيعتمد على القراءة بشكل كبير، ممكن نوسع النظام بسهولة عن طريق إضافة نسخ مكررة للبيانات.
بالنسبة لعمليات الـ WRITE: عمليات الكتابة بتحتاج لموارد أكتر. لما تكتب بيانات، لازم تتحفظ في التخزين، وده بيحتاج لتنسيق أكتر وبيسبب تأخير، خاصة في الأنظمة الموزعة. الكتابة كمان ممكن تشمل تحديث الفهارس أو التعامل مع سجلات المعاملات. عشان كده، توسيع النظام علشان يستوعب الكتابة بيدفعنا لزيادة الموارد بشكل أكبر وأصعب.
دي كانت المشكلة تعالى نتكلم عن الحل.
CQRS Pattern
الـ CQRS هو Pattern نمط بيفصل بين العمليات اللي بتعمل استعلامات (queries) والعمليات اللي بتنفذ أو بتعدل بيانات (commands) في التطبيق. الفصل ده بيسمح لك إنك تستخدم different data models موديلات بيانات مختلفة لكل حالة، وبالتالي التطبيق بيبقى أكتر مرونة.
التعديلات اللي بتعملها مش هتأثر على باقي الأجزاء في التطبيق، وده لأن مفيش حاجة هتحتاج lock tables or records قفل جداول أو سجلات عشان تعمل updates تحديثات، وده كان بيؤثر سلبًا على الأداء.
كمان تقدر تخصّص البيانات حسب احتياجات الاستعلامات(queries) ، وده بيسمح لك كمان تستخدم تقنيات تخزين مختلفة بناءً على احتياجات الاستعلام(queries). بالإضافة لذلك، تقدر توزع وتكبر عمليات القراءة والكتابة بشكل منفصل، وده بيخلي استهلاك الموارد أكتر كفاءة وأقل تكلفة في البنية التحتية.
دي صورة بتوضح المشكلة :
ودي صورة بتوضح الحل بتطبيق ال CQRS :
خدت بالك من ال DAL في الصورتين :
لما التطبيق بيقرأ بيانات، ممكن يحتاج ينفذcomplex queries استعلامات معقدة عشان يطلع Data Transfer Object (DTOs) في هياكل مختلفة different structures، وده ممكن يسبب تعقيد في عملية تحويل البيانات . (object mapping)
من ناحية تانية، لما بيكتب بيانات، النموذج ممكن يحتوي على عمليات تحقق معقدة (validation) و (business logic)، وده ممكن يخلي الmodel يبقى معقد جدًا وبيتحمل multiple responsibilities مسؤوليات كتير.
وده اللي هتلاقيه اتعالج واتصلح في الصورة التانية باستخدام ال CQRS .
تقدروا دلوقتي تشتركوا في النشرة الأسبوعية لاقرأ-تِك بشكل مجاني تمامًا عشان يجيلكوا كل جديد بشكل أسبوعي فيما يخص مواضيع متنوعة وبشروحات بسيطة وسهلة وبجودة عالية 🚀
النشرة هيكون ليها شكل جديد ومختلف عن شكلها القديم وهنحاول انها تكون مميزة ومختلفة وخليط بين المحتوى الأساسي اللي بينزل ومفاجآت تانية كتير 🎉
Eqraatech - اقرأ-تِك
بفضل الله قمنا بإطلاق قناة اقرأ-تِك على التليجرام مجانًا للجميع 🚀
آملين بده اننا نفتح باب تاني لتحقيق رؤيتنا نحو إثراء المحتوى التقني باللغة العربية ، ومساعدة لكل متابعينا في انهم يوصلوا لجميع أخبار اقرأ-تِك من حيث المقالات ومحتوى ورقة وقلم والنشرة الأسبوعية وكل جديد بطريقة سريعة وسهلة
مستنينكوا تنورونا , وده رابط القناة 👇
Mediator Pattern
طيب فهمنا المشكلة والحل ايه بقى موضوع ال Mediator pattern ده ؟
ال Mediator pattern بيهدف لتقليل الاعتمادية بين الكائنات (objects) يعني بي reduce dependencies between objects وده من خلال انه بيمنع الاتصال المباشر بينهم.
طيب بيكلموا بعض ازاي ؟ بيكلموا بعض عن طريق كائن وسيط (mediator).
ببساطة، فيه كائن واحد (mediator) بيتولى تنظيم وإدارة كيفية تفاعل الكائنات (objects) التانية مع بعض. يعني بدل ما الكائنات (objects) تتكلم مع بعض بشكل مباشر، هي بتتواصل مع الوسيط (mediator) اللي بيشوف ويدير التفاعل بينهم.
طيب وايه كانت المشكلة عشان يخترعو ال Mediator pattern ؟
المشكلة كما بالشكل :
هتلاقي هنا ال objects بتتواصل بشكل مباشر بتكون عادة مترابطة بشكل قوي (tightly coupled). في الحالات دي، أي تغيير في object واحد ممكن يؤثر على الكائنات التانية، وده بيؤدي لتغييرات تانية في النماذج (models)، السكربتات (scripts)، وغيرهم.
كمان كل object لازم يكون عارف بالواجهات (interfaces) والتطبيقات (implementations) الخاصة بالكائنات objects التانية اللي بيتفاعل معاها. وده بيخلي النظام أكثر تعقيدًا في الفهم والصيانة والتطوير. المشكلة دي بتكبر مع مرور الوقت زي كرة الثلج، وبتؤثر بشكل مباشر على المطورين والإدارة، وأخيرًا على المنتج النهائي اللي بيستخدمه العملاء.
عشان كده الحل هو ال Mediator pattern: عندنا اكتر من service بيكلموا بعض من خلال a mediator object. كائن وسيط . وده بيخلهم more flexible مع simplified interactions and reduced dependencies واحسن واسهل في الصيانة
طيب ايه دور Mediator pattern في ال CQRS، هتلاقي أنه فيه فَصل بين الـ Commands (اللي بتعدل البيانات) و الـ Queries (اللي بتسترجع البيانات).
هنا بيجي دور الـ Mediator في تنظيم التفاعل بين الأوامر والاستعلامات. الـ Mediator بيكون مسؤول عن توجيه الأوامر (Commands) والاستعلامات (Queries) بشكل مناسب للوحدات أو الخدمات المتخصصة في التعامل مع كل منها، وبالتالي بيعزل الكائنات عن بعضها ويسهل التوسع والصيانة.
باختصار:الـ Mediator بيعمل كحلقة وصل بين الأوامر والاستعلامات في تطبيقات الـ CQRS، مما يسمح بفصل مسؤوليات القراءة والكتابة عن طريق إدارة التواصل بينها بشكل أكثر تنظيماً وكفاءة.
في الختام
استخدام ال architectural pattern المناسب ليه تأثير كبير علي كفاءة النظام وقدرته علي التوسع. عرفنا في هذه المقال أكثر عن ال CQRS Pattern و ال Mediator Pattern وإزاي بيتم استخدامهم سويًا لخلق نظام برمجي عالي الكفاءة.
