في الDomain Driven Design هناك مصطلح الAggregates. اقرب ترجمة له برأيي هي عنقود. كعنقود العنب الذي في الصورة. و الAggregate Root هو الجذر في الأعل و الذي نمسك و نتعامل به مع العنقود. ال3 او ال4 عناقيد التي في الشجرة الواحدة تقابل Bounded Context. و المزرعة ككل هي برنامجك.
-سلسلة
-سلسلة
لو قارنا بيت منزل عادي و بين عمارة , وحدة البناء في كليهما هي "الطوب" او ال"البلك" و اللي ممكن عدها , العمارة طبعاً اكثر عدداً و هذي الكثرة انتجت لنا مميزات اكثر متمثلة بكثرة الغرف و المرافق و الوحدات كالشقق.
في الأنظمة البرمجية وحدة البناء هي اسطر الكود , فهل ياترى عدد الأسطر في انظمتنا يتناسب طردياً مع عدد المميزات التي يقدمها النظام؟ إذا كانت الاجابة لا فهناك مشكلة. مشكلة تتمثل بكلمة "تعقيد" Complexity. اسطر برمجية لا داعي لها.
كتاب @ericevans0 الأزرق Domain Driven Design يشرح هدفه في عنوانه الفرعي : Tackling Complexity in the Heart of Software. حل او نزع التعقيد في قلب البرامج.
كلمة قلب مهمة هنا .. فنحن نتكلم عن لُب البرنامج ... حيث الEntities في الClean Architecture كما في الصورة.
كلمة قلب مهمة هنا .. فنحن نتكلم عن لُب البرنامج ... حيث الEntities في الClean Architecture كما في الصورة.
الاسبوع الماضي تكلمت عن الValue Objects و انها اشياء تعكس شيء في الواقع ليس له هوية. مثل الريال او الجنيه او الدرهم .. لو اعطيت شخصاً 5 ريالات ثم طلبت استرجاعها , فهل ستشترط أن يرجع لك نفس الورقة النقدية بالرقم التسلسلي ام أي 5 ريالات ؟!!. نحن نتعامل هنا بالValue و ليس بالهوية.
على عكس الValue Object الEntity هو Object بهوية ( Id ) كجهاز هاتفك , سيارتك , صديقك , اخوك. كما قال دنقل : "أقلب الغريب كقلب أخيك؟!". التفريق بين الاثنين يعتمد على اهمية تتبع و تحديد الObject بذاته بالنسبة للBusiness.
هناك قاعدة لكن استخدمها بحذر للتفريق بين الEntities و الValue Object و هي ان الEntities تحتاج دائماً Row بـID في قاعدة البيانات اما الValue Object فتكون في نفس Row الخاص بالـ Entity. اي قد تضيف حقلين لعنوان التوصيل في سطر الفاتورة مباشرة.
لنأخذ موقع امازون كحالة. بلا شك الUser هو Entity و الItem ( المنتج ) Entity الShopping Cart ؟. في امازون Entity و الItemLine الذي يمثل عنصر من عناصر الShopping Cart ايضاً Entity. عنوان الكتاب, صورته, نوعه و الاشياء الأخرى الصغيرة ValueObject فلا نريد عنوان بطول 1000 حرف مثلا.
وضعت امام الShopping Cart علامة استفهام. لانه من الممكن ان تكون ValueObject إذا لم نكن مهتمين بحفظها في قاعدة البيانات كـCart و انما مهتمين بحفظها بعد أن تصبح Order فقط. لكن من الأفضل معاملتها ليس فقط كـEntity و انما كـ Aggregate Root.
الAggregates ليست Class كالValueObject او الEntity هي فقط Pattern فكرتها ان تتعامل مع عدة Objects كوحدة واحدة ( عنقود عنب) لكن الAggregate Root هو Class و أهم كلاس حيث انهو مدير باقي الِAggregates سواء كانت Entities او ValueObjects او اشياء اخرى.
لاحظ مرة اخرى في الصورة أن هناك رابط Delete و الذي يفترض ان يقابله Method في الAggregate Root و الذي هو الShopping Cart. كذلك بالنسبة لSave for Later و قائمة الكمية التي ممكن ان يقابلها ChangeQuantityTo مثلا.
من الواضح ان لدينا Aggregates كاملة هي الShopping Cart. وهي ليست الOrder. فالCart ليس بها معلومات الشحن و الدفع. اذا الOrder هو Aggregates مختلفة في كلاس Order الذي سيكون هو الAggregate Root. لكن كيف سننقل معلومات الCart و نحولها إلى Order عند الضغط على زر Proceed to checkout؟
هنا يأتي دور الDomain Events. و التي من مهامها التخاطب بين الAggregate Roots. و ستكون له سلسلة مستقلة.
هذا و دمتم.
هذا و دمتم.
جاري تحميل الاقتراحات...