نمذجة المجال
الدرس 19 من 38 · التصميم · 8 دقيقة و55 ثانية
الفيديو الأصلي باللغة الإنجليزية. إذا تعذّر تشغيله هنا، شاهده على موقع المؤلف. التفريغ النصي العربي الكامل أدناه.
الموارد
التفريغ النصي
[00:03] لنتحدث عن واحدة من أقوى الأدوات في مجموعة أدوات مصمّم البرمجيات: نمذجة المجال. إنها طريقة لاكتشاف كيانات النظام ووصف سماتها وعملياتها. وقوّتها نابعة من مرونتها: عند بناء طبقة البيانات، يمكن استخدامها لوصف مخطط قاعدة البيانات وتحديد الجداول المطلوبة وأعمدتها وأنواع الأعمدة، وما إلى ذلك. وفي البرمجة الكائنية، تساعد على تعريف الأصناف والواجهات الرئيسية للنظام. أما في تطوير الواجهات الأمامية، وهو ما يهمّنا هنا، فتساعدنا على تنظيم البنية ومواءمتها مع واجهة المستخدم.
[00:51] هناك مجموعة من الأماكن حيث يمكننا العثور على هذه الكيانات من نظامنا، ولكن بالنسبة لأنظمة الواجهة الأمامية على وجه الخصوص، هناك طرق أود أن أبدأ بها هي المتطلبات الوظيفية لنظامنا ومواصفات واجهة المستخدم. إذا ألقينا نظرة على مواصفات المشروع، والتي ستجد رابطًا لها في وصف هذا الفيديو، فسنرى هنا قائمة المتطلبات الوظيفية. هذه هي نفس تلك التي رأيناها في الوحدة السابقة. وإذا قرأنا من خلال هذه، فسنجد أن هناك الكثير من الأسماء التي تتكرر كثيرًا، ولديهم الكثير من الإجراءات المرتبطة بها.
[01:25] لذا فإن الأسماء في هذه القائمة، في وصفها للتطبيق أو المتطلبات الوظيفية، تمثل عادة كيانًا وتمثل الأفعال الإجراءات التي يمكنهم اتخاذها. لذلك سنرى هنا أن الكثير من العمليات، والكثير من ميزات النظام مرتبطة بالعملاء، مما يعني أن العملاء ربما يكونون أحد الكيانات الأساسية لنظامنا. ونحن نرى أيضا بعض المتعلقة المطاعم والمواد الغذائية، مما قد يعني هذه هي أيضا كيانات هامة جدا من نظامنا. ويمكننا أن نقرأ من خلال هذه ونجد أي كيانات أخرى قد تكون لدينا.
[01:58] والأماكن الأخرى التي أحب أن أبحث عن الكيانات والسمات هي على جوانب واجهة المستخدم نفسها. حتى هنا لدينا هذا الملف Figma الذي كتذكير هذا فقط لقطات من Ubereats، وهو تطبيق النموذج الذي نستخدمه لوصف FullSnack في تطبيق وهمية لدينا. وهنا يمكننا، يمكننا التنقل عبر بعض الصفحات الرئيسية. هذه بعض الصفحات الرئيسية للتطبيق. وإذا نظرنا إلى صفحة المطعم هذه، على سبيل المثال، سنرى أن لدينا هنا الكثير من السمات المختلفة التي يمكننا ربطها بكيان مطعمنا.
[02:31] نقرر أن المطعم هو أحد كياناتنا، أحد الكيانات الأكثر أهمية. لذا بالنظر إلى مواصفات واجهة المستخدم، يمكننا تحديد سماتها وعملياتها. لذلك يمكننا أن نرى أن المطاعم لها اسم، وأن لديهم شعار، صورة من نوع ما، أن لديهم نوعا من لافتة صورة البطل في الأعلى. لديهم أيضا بعض المعلومات رسوم التسليم المرتبطة بها. لديهم بعض المعلومات وقت التسليم ولديهم علاقة مع كيانات أخرى كذلك. لذلك نرى هنا أن المطاعم لديها مجموعة من الفئات للمواد الغذائية التي لديهم. لديهم مجموعة من المواد الغذائية وكذلك عناصر القائمة. ومن ثم لدينا بعض المراجعات التي يمكن أيضا أن تكون كيانات من تلقاء نفسها.
[03:21] إذن كيف نحيط علماً بهذا؟ الطريقة التي أحب أن مجرد تعريف الكيانات بلدي، كل يستخدم قائمة بسيطة جدا. لذلك لدينا هنا مثال على كيف يمكنني تتبع كياناتي. مجرد قائمة من الكيانات التي أكتشفها وأنا أذهب من خلال مواصفات الشكل أو هذا الوصف لميزاتي. وبالنسبة لكل كيان قد يكون لدي قائمة ببعض سماته الرئيسية وعملياته أو عملائه. نرى أن لدينا، ربما سيكون لدينا معرف للعملاء، اسم، بريد إلكتروني إضافة إلى عملية المفضلة، والتي هي واحدة من الإجراءات التي يمكنهم القيام بها. وبالنسبة للمطاعم أيضًا، قد يكون لدينا معلومات أخرى هنا.
[04:00] إذا كنا نحب أن نضع معا تمثيل مرئي لمجالنا، يمكننا الاستيلاء على هذه القائمة ووضعها في مخطط فئة. يمكننا وضع رسم تخطيطي للصف أو رسم تخطيطي لعلاقة الكيان، وسنرى كيف يمكننا القيام بذلك في أحد مقاطع الفيديو التالية.
[04:10] الآن، إليك سؤال قد يكون لديك الآن. لماذا تفعل كل هذا؟ لماذا يهم هذا؟ هل يمكننا فقط إلقاء نظرة على مواصفات واجهة برمجة التطبيقات، واستجابتها عبر واجهة برمجة التطبيقات وتحديد كياناتنا والنماذج من ذلك؟ حسنًا، نعم، يمكننا القيام بذلك، ولكن هناك بعض الأسباب التي تجعل القيام بهذا التمرين لنمذجة المجال في وقت مبكر، وتحديدًا في بداية المشروع، مفيد للغاية.
[04:34] الأول هو أنه يسمح لنا بالقيام بأحد أصعب الأشياء لمطوري البرمجيات بشكل عام، وهو تسمية الأشياء بإعطاء هذه الكيانات أسماء مناسبة. لذلك، على سبيل المثال، قررنا أننا سنسمي أحد مطاعم الكيانات الخاصة بنا، وهذا يعني أنه يمكننا استخدام هذه الكلمة، كلمة مطعم، للإشارة إلى الكثير من الأشياء المرتبطة بكيان ما. لذلك في الشيفرة، قد يكون لدينا فئة مطعم وموقع مطعم ووظيفة getRestaurantInfo. وكل هذه الأشياء تستخدم كلمة مطعم. وكلما رأينا أسماءهم، نعلم أننا نشير إلى كيان المطعم هذا.
[05:15] إذا لم نأخذ الوقت والجهد لتسمية الكيان، فسيتم تحديد التسمية بأن أيًا كان من ينفذ هذه الميزة والأشخاص المختلفين سيعطون أسماء مختلفة لنفس الشيء. لذلك في بعض الأحيان قد نشير إليها كمطاعم، وأحيانًا كمتجر وأحيانًا كمتجر. وسيكون الأمر مربكًا للغاية لأننا لن نعرف ما إذا كانت هذه كلها نفس الشيء. هل نحن جميعاً نشير دائماً إلى نفس الكيان، أم أن هناك فرقاً بين مطعم ومتجر؟
[05:43] على سبيل المثال، تذكر أن هذه الكيانات أساسية لنطاقك، لذلك قد تتغير ميزات منتجك. يمكنك إضافة chatbot AI ويمكنك إزالة chatbot AI ويمكنك إضافة مجموعة من الميزات المختلفة للمنتج، ولكن من المحتمل أن تبقى الكيانات على قيد الحياة. حتى قاعدة الشيفرة نفسها، يمكنك إعادة كتابة قاعدة الشيفرة الخاصة بك بالكامل باستخدام إطار مختلف بعد خمس سنوات من الآن، ولكن هناك احتمالات بأن يكون للتطبيق الخاص بك دائمًا مطاعم، وسيكون لديه عملاء دائمًا وسيكون لديه دائمًا عربات تسوق ومواد غذائية. لذا فإن تسمية هذه الأشياء بشكل صحيح، ومنحهم الأسماء المناسبة في هذه المرحلة أمر مفيد للغاية.
[06:17] والسبب الثاني هو أن القيام بهذا التمرين يسمح لنا بمواءمة نموذج البيانات مع واجهة المستخدم. لذلك إذا لم نأخذ الوقت الكافي للتوصل إلى نموذج بيانات تحتاجه واجهة المستخدم الخاصة بنا، فمن المحتمل أننا سنستخدم أي نموذج بيانات يأتي من الخادم. قد نحاكي نموذج بياناتنا باستخدام، كما تعلمون، أيا كان، هذا الهيكل لقاعدة البيانات. لذلك في هذه الحالة قد يكون لدينا استجابة واجهة برمجة التطبيقات التي تبدو شيئا من هذا القبيل لتمثيل كيان مطعمنا. وهنا نرى أن الكثير من البيانات هي معرفة متداخلة بعمق. لذلك للوصول إلى الاسم، يجب أن أذهب إلى ثلاثة مستويات ومن ثم لدينا بعض البيانات التي نحتاجها مثل معرف المنطقة، ربما لا أحتاج إلى هذه المعلومات في واجهة المستخدم وعلاقاتي، مثل فئاتي، في تنسيق غير مفيد لي.
[07:08] لذلك إذا قمنا بنمذجة نموذج البيانات بعد واجهة المستخدم، فقد نخرج بكيان يشبه هذا. هذه هي خصائص كياننا. الآن، بالطبع سيكون هناك معالجة، والتي يتعين علينا تحليل البيانات أو تحويل بنية البيانات هذه إلى بنية أخرى. ولكن هذا المنطق سوف يغلف. لذلك سنقوم بإزالة الكثير من هذا التعقيد الذي يأتي مع الاضطرار إلى العمل مع هياكل البيانات هذه التي لم يتم تصميمها بعد واجهة المستخدم نفسها.
[07:33] وأخيرًا، هناك سبب آخر يجعل من المفيد القيام بتمارين نمذجة المجال هذه هو أنها تسمح لنا بإجراء محادثات مثيرة للاهتمام مع فرقنا حول كيفية تحديد المسؤولية بين كياناتنا المختلفة. لذلك دعنا نقول، على سبيل المثال، أننا نحدد هذه الإضافة إلى عملية العربة التي تتضمن كيانات متعددة. وهو ينطوي على المستخدم الذي يضيف الإضافة إلى العربة. وهو ينطوي على العنصر نفسه الذي تتم إضافته ويتضمن كيان العربة أيضًا. إذن من المسؤول عن هذه العملية؟
[08:03] قد نقول أنه ليس لدينا معلومات كافية في هذه المرحلة لإجراء هذه المكالمة، أو قد نقوم ببعض الاكتشافات وقد نكتشف أن لدينا بالفعل شرطًا ينص على أنه يمكن للمستخدمين بالفعل الحصول على عربة تسوق متعددة واحدة لكل مطعم يضيفون عناصر منه. لذلك لدينا الآن نقطة إضافية من المعلومات. قد نقرر أن العنصر لا ينبغي أن يكون مسؤولاً عن ذلك، لأنه يجب ألا يعرف أي شيء عن عربات التسوق الأخرى الموجودة ونفس الشيء بالنسبة للعربة، يجب ألا تعرف أشياء عن عربات التسوق الأخرى غير نفسها. لذلك قد تقول أن هذه هي مسؤولية المستخدم. أو ربما تكون مسؤولية كيان المطعم إنشاء عربة تسوق لنفسها.
[08:41] لا يهم أين نقرر أن نضع هذه العملية النقطة المهمة هي أن إجراء هذه المناقشات الآن وتغيير القرار في هذه المرحلة أرخص بكثير من تغييره بعد تنفيذ الشيفرة بالفعل.