لو اعتبرنا ان عقل الإنسان عبارة عن برنامج فسنرى انه يعمل بطريقة تجعل وعينا الحاضر حول اي موضوع عبارة عن محصلة حسابية لأحداث تاريخية كثيرة ( بيانات مختلفة وصلتنا عبر حواسنا ) لها علاقة بذلك الموضع و قام العقل بمعالجتها ليصبح فهمنا على ما هو عليه بشأنها. ( سلسة )
فالعقل لا يقوم بعمل Override لمعلومات قديمة و يستبدلها بمعلومات احدث بل كل المعلومات حاضرة لكننا نميز الأصح و الأحدث لنصل إلى الـ( Current State ) و الوعي الحالي الذي نحن عليه.
عملياً نجد انظمة البنوك الخاصة بالحسابات تستخدم نفس الطريقة لحساب رصيدنا الحالي و الذي هو عبارة عن محصلة ما أودع في حسابنا مع ما انفقنا. طبعاً ليس من المعقول ان تقوم تلك الانظمة بقراءة جميع عملياتنا البنكية من تاريخ فتح الحساب إلى الان لتقول لنا ماهو الرصيد.
حيث انه من الممكن ان نحتفظ باخر رصيد في مكان ما اخر لغرض تسريع القراءة و نقوم بتحديثه مع كل حدث Event يتم على الحساب إما بالزيادة او الحسم. هذا يتم في مكان اخر في قاعدة بيانات اخرى لكن تبقى البيانات الرئيسية القادمة من الاحداث immutable غير قابلة للتعديل.
عندما نقول Event ( حدث ) فنحن نعني شيء حدث في الماضي و انتهى و الماضي immutable لا يمكن تغييره .
أي نظام برمجي سواء موبايل او ويب او خدمة داخلية يتحرك ويعمل بال Events بدءاً من تشغيل البرنامج إلى تسجيل المستخدم و دخوله ثم ضغطه على الازرار او تحرك الشاشة كلها Events g لكن نختلف في طريقة معالجتنا لتلك الاحداث فهناك طريقتين اساسيتين.
إما أن نفكر في البيانات و شكلها و هذا الاغلب وعليه نصمم قواعد بياناتنا و كلاساتنا Data Model و إما ان نفكر في سلوك البرنامج او الBehavior و هنا نصمم الكلاسات حسب البزنس Domain Model
الطريقة الاولى معروفة و شائعة اما الثانية فهي التي تمكننا بأن نخرج عن التفكير النمطي في تصميم قواعد البيانات و هي التي تمكننا من بناء نظام متكامل من جدول واحد يحتوي ثلاثة حقول
حقول مثل ID للحدث يكون GUID و رقم النسخة Integer و الPayload الذي يحتوي بيانات الحدث و عادة يكون الحقل من نوع JSON اذا كانت قواعد البيانات تدعمه مثل MySQL او String او CLOB . هذا مفهوم الEventSourcing
او Event-driven architecture ( يتبع ... )
او Event-driven architecture ( يتبع ... )
جاري تحميل الاقتراحات...