الـ Event Sourcing قوي جدًا لما تكون محتاج بجد تتابع تاريخ التغييرات اللي بتحصل على حالة التطبيق. بس ده بيجي معاه تكلفة: تعقيد أكتر، استهلاك مساحة تخزين، وصعوبة في التشغيل. خلّي الـ stack بتاعك بسيط قد ما تقدر—وفكّر مرتين (ولو تلاتة) قبل ما تعتمده.
زي ما Martin Fowler عرّفه:
"الفكرة الأساسية في Event Sourcing هي إن كل تغيير في حالة التطبيق بيتسجّل كـ event object، والأحداث دي بتتخزن بالترتيب طول عمر حالة التطبيق."
لو لسه جديد على المفهوم ده، أنصحك تقرأ المقال الكامل بتاعه عشان تفهم الصورة كاملة. الهدف من البوست ده مش إعادة شرح Event Sourcing، لكن توضيح إمتى ماتستخدمهوش.
مش بالضرورة. الـ Event Sourcing ليه مكانه، لكن هو أعقد من إنك مجرّد تحدّث قيم في التطبيق.
بدل ما تكتب فوق الحالة القديمة، في Event Sourcing لازم:
وده بيضيف عبء ذهني وتقني كبير. لو مش محتاج audit trail أو إعادة تشغيل للتاريخ، غالبًا الأفضل تبعُده عنه.
لأ. صحيح إن CQRS (Command Query Responsibility Segregation) والـ Event Sourcing بيظهروا كتير مع بعض، بس مش مربوطين ببعض بشكل أساسي. في أُطر عمل بترّبطهم، لكن تقدر تستخدم CQRS من غير Event Sourcing. الاختيار لازم يكون حسب طبيعة المشكلة، مش الموضة.
فكّر فيه لو محتاج:
الأفضل تتجنبه في:
الـ Event Sourcing من الأنماط اللي شكلها أنيق في النظرية، لكن ممكن يسبب إهدار وقت، إحباط، وتعقيد من غير لازمة لو اتطبق غلط.
👉 استخدمه بس لو حالتك فعلاً محتاجة تاريخ كامل للأحداث—مش عشان شكله جامد أو عشان framework بيدعمه.
👉 قرار واعي من الأول ممكن ينقذ فريقك من شهور من الديون التقنية بعدين.