هذه مقولة ليست لروائي او صحفي او مؤلف نصوص و انما لرسام كرتون فالافكار هي الافكار و التدوين قد يكون نص او رسم او حتى كود. و عليه فقد يصحح الكود مشكلة في فهم البزنس نفسه لدى المنشأة. لم يدون إيريك ايفان مبتكر الDDD كل شيء عنها في كتابه لكن قد تلتقطها من بين الاسطر.
يتبع
يتبع
تكلم ايريك عن الDomain واعطى طرق لتحديد ماهو الAggregate و ماهو الAggregate Root. لن ادخل في المصطلحات الان. لكن لنأخذ حالات كأمثلة قد توضح المشكلة بشكل افضل. و ليكن مثالنا موقع booking.com لحجز الفنادق.
يتبع ..
يتبع ..
بعيد عن البرمجة , ماهو الشيء الذي يمثل الاساس للخدمة؟ هل هو الحجز ؟؟ اذا كان ذلك صحيحاً فالحجز لا يتم الا بوجود فندق!. اذا الفندق هو الاساس .. لكن بالنسبة للعميل هو لا يريد اي فندق مثلما لو اشترى بضاعة من موقع امازون ولكن يريد فندق في مدينة معينة .. اذا المدينة هي الاساس
يتبع
يتبع
لكن حتى المدينة لو كانت هي الاساس فانا لا احتاجها في كل الاوقات, احتاجها في تاريخ معين .. وهنا نعود للحجز نفسه. هذه الافكار تمتحنها الكود, فابمكانك كمبرمج ان تختار اياً مما ذكر في الاعلى و تبني عليه النظام.
تتبع
تتبع
لكن حتماً ستواجهك مشاكل و سيكون اسهل لك في التطوير اخذت اساساً غير الاخر و هنا تتحقق المقولة السابقة بخصوص فحص الافكار. الوصول للاساس ليس بالامر السهل. خذ مثلا برامج حجز تذاكر الطيران , من الاصل , هل هي الطائرات ام المطارات ام موقع المطارات ام التوقيت؟
يتبع
يتبع
هناك اشياء تبدو واضحة جداً من وجهة نظر البزنس لكن قد يكون وضوحها خداعاً. كيف ترى مالا يُرى؟ قد تحتاج لاختراع شيء تخيلي كأساس وان كان ليس له وجود في الواقع كالاعداد التخيلية عند الرياضيين فقط لكي تحل مشاكل كهذه معتمد على فهم عميق لحاجة العميل و للعمل نفسه ( الدومين).
انتهى.
انتهى.
جاري تحميل الاقتراحات...