Ahmed Aljaberi
Ahmed Aljaberi

@ahmed_aljabri

11 تغريدة 36 قراءة May 24, 2020
الClass مجرد مصنع للObjects. و الObjects هي تمثيل مبسط او نمذجة لعناصر المشكلة التي نحاول حلها بحيث يسهل علينا التعامل معها. فمثلاً لدينا نظام فيه موظف فنقوم بإنشاء Class اسمه Employee. و لدينا "مال" نقوم بنمذجته بClass اسمه Money.
( سلسلة )
كلمة تحليل و تصميم Analysis and Design عادة تأتي مع بعضها كعنوان للكتب او للدورات. لكن هناك شيء مهم و هو ان التحليل يكون للمشكلة ( الوضع الحالي ) و التصميم يكون للحل ( الوضع المستقبلي). لذا إريك ايفان اوجد مصطلحي الProblem space و الSolution space في الDDD.
عودة للمثال السابق عن الEmployee و الMoney سنضيف إليهما كلاسات اضافية هم Order و Calculator و Customer. لأنه في الواقع يقوم الموظف باستلام مبلغ محسوب من العميل.
هناك طريقتين رئيسيتين في نمذجة ماسبق من خلال الClasses
فإما ننظر لهما كـData و نقوم بإنشاء جداول لهم ثم كلاسات لحمل تلك الData او ننظر إليهم كاشياء Objects حقيقية على ارض الواقع بينهم تفاعل و هذا الفرق بين أن يكون لدينا كلاس حقيقي او مجرد data type.
الخمسة اشياء السابقة ستكون كلاسات في كلا الحالتين لكن لها أنواع. اذا استخدمنا طريقة الجداول و نظرنا لها على انها مجرد أوعية للبيانات فليس هناك فرق يُذكر بينهم .. لان جميعهم Data types. لكن بالطريقة الاخرى هناك الكثير ...
الEmployee و الCustomer هؤلاء Actors أناس حقيقين فاعلين لهم هوية , و الMoney مجرد قيمة او حاوية لقيمة , و ال Calculator هي خدمة لإحتساب للمبلغ لا هوية لها و الOrder له هوية و هو المنظم بينهم و المدير للأحداث التي تحصل بينهم و هو الهدف او الرابط بينهم.
لاحظ ان النظرة هنا تغيرت , اصبح لدينا اشياء يمكن تقسيم نظامنا على اساسها حسب وظيفتها في الواقع . ايضاً لاحظ ان الرابط بين تلك الObjects هي الأحداث التي تتم بينها , الCustomer يطلب شراء و الEmployee يستجيب بإنشاء Order فيه Money تم احتسابه عن طريق الCalculator
في الDDD .. مجموعة الClasses تلك تسمى Aggregates و المنظم لها الذي هو الOrder يسمى Aggregate root
و الEmployee و الCustomer يسمى Entity و الCalculator يسمى Service و الMoney يسمى ValueObject.
و الأحداث ايضاً كلاسات تسمى Domain Events.
تلك الAggregates كونت بتفاعلها فيما بينها فائدة للبزنس و قد تشترك مع Aggretages أخرى كالتوصيل لتخلق بايسمى بالBounded Context الذي يمكن ان يمثل Microservice مستقلة.
الهدف مما ذكر ليس بناء نظام سريع او ذو تقنية عالية و انما هو أداة لتحليل و تصميم و بناء الأنظمة المعقدة حينما يكون هناك الكثير من الفاعلين في البزنس مع اشتراطات و احكام و حالات كثيرة فيتم تبسيطة بالطريقة التي ذكرتها بحيث نكون قريبين لواقع البزنس و محاكين له قدر الإمكان.
ربما ما ذكرته بسيط لكن سيوفر عليكم الوقت فيما لو حاولتوا فهم الDDD من كتاب او من دورة و هناك اشياء كثير غير التي ذكرت
فما ذكرته يعتبر جزء يسمى الtactical design . كانت هذه نظرة بسيطة على الDomain Driven Design. و دمتم.

جاري تحميل الاقتراحات...