من أين تبدأ عند القيام بنموذج المجال؟

Question

دعنا نقول أنني قدمت قائمة بالمفاهيم التي سأستخدمها لرسم نموذج النطاق الخاص بي. علاوة على ذلك ، لدي بعض الحالات الاستخدام التي قمت بها ببعض مخططات تسلسل النظام.

عند رسم نموذج المجال ، لا أعرف أبدًا من أين أبدأ من:

1. تصميم النموذج كما أعتقد أن النظام ليكون. هذا ، إذا كنت أقوم بتصميم جسم الإنسان ، فأنا أبدأ بإضافة مفاهيم القلب من القلب والدماغ أو الأمعاء والمعدة والعينين والرأس ، إلخ.
2. ابدأ بتصميم ما تحتاجه حالات الاستخدام. هذا ، إذا كان لدي حالة استخدام تدور حول جعل جسم الإنسان يبتلع شيئًا ما ، فسأرسم أولاً مفاهيم الفصل للفم ، الحلق ، الطبق ، الأمعاء ، إلخ.

الترتيب الذي أفعله بالأشياء غير ذي صلة؟ أود أن أقول من المحتمل أنه سيكون من الأفضل محاولة التصميم من مفاهيم حالة الاستخدام ، لأنها عمومًا ما تريد العمل معه ، وليس نوعًا آخر من المفاهيم التي تساعد في وصف النظام بأكمله جيدًا ، إلا أن معظم الوقت قد لا تكون هناك حاجة حتى للمشروع الحالي. هل هناك أي نهج آخر لا أخذه هنا؟ كيف تقترب عادة من هذا؟

شكرًا

Answer 1

سأبدأ برسم مخطط الفصل مع جميع العلاقات وتنفيذ فقط الفصول الضرورية وفقًا لمتطلبات التطبيق الخاص بك.

يمكنك استخدام نهج فقر الدم (السمات بالإضافة إلى getters والمستقبين) للحفاظ على الأمور بسيطة وتجنب خطوة كتابة منطق الأعمال في نفس الخطوة. مع نموذج فقر الدم ، سوف يذهب المنطق إلى فئة الخدمة المقابلة. بهذه الطريقة يمكنك التفكير في استخدام حالات لاحقًا.

أعلم أن بعض الناس لا يقدرون هذه الطريقة في القيام بالأشياء ، لكنها تساعد في الصيانة وتجنب بعض مشكلات التبعية.

إجابة على سؤال الإليسيوم أدناه:

من حيث التحليل ، بدءًا من حالات الاستخدام (ماذا) ثم الانتقال إلى الرسم البياني للصف (كيف) يبدو وكأنه قاعدة جيدة. شخصياً ، سأقوم بعمل مخطط التسلسل (متى ومن؟) بعد ذلك ، كما تحتاج إلى معرفة بين الرسائل/الكائنات التي يجب إرسالها.

علاوة على ذلك ، فإن رأيي في الأشياء هو أن UML هو ببساطة وسيلة لتصميم نظام/مشروع وليس منهجية في حد ذاته (على عكس Merise ، RAD ، RUP ، SCRUM ، إلخ). لا يوجد شيء يمنع شخص ما يبدأ بأي رسم تخطيطي طالما كان لديه المعلومات الكافية لإكمالها. في الواقع ، يجب أن يتم ذلك في وقت واحد لأن كل من المخططات هو منظور مختلف لنفس النظام/المشروع.

لذلك ، الكل في الكل يعتمد على كيفية التحليل. خلال دراستي ، تعلمت نهج الشلال الصلب ، حيث تقوم بتحليل كامل من البداية إلى النهاية قبل إنتاج بعض التعليمات البرمجية. ومع ذلك ، يمكن أن تكون الأمور مختلفة في الممارسة العملية ، حيث قد يكون من الضروري إنتاج تطبيق عمل في أقل وقت ممكن.

على سبيل المثال ، تعرفت على منهجية Scrum مؤخرًا لتمرين يتضمن إنشاء موقع ويب حيث يمكن للأشخاص نشر رواياتهم. نظرًا لوجود قيود زمنية ورؤية واضحة لما ينبغي تحقيقه ، بدأنا على الفور مع رسم تخطيطي فئة العظام لتمثيل نموذج المجال. ثم تم استنتاج حالات الاستخدام من سلسلة من الشاشات الوهمية التي أنتجناها.

من الذاكرة ، كانت الفصول القصة والفصل والمستخدم والفئة. تم التخلص التدريجي من هذه الفئة الأخيرة لصالح فئة العلامات الأكثر مرونة. كما تتخيل ، سيكون الرسم البياني للفصل الكامل للمشروع الحالي أكثر تعقيدًا بسبب تطبيق تصميم المجال وخصائص لغة برمجة Java.

يمكن اعتبار هذا النهج قذرًا. ومع ذلك ، يمكن بسهولة صنع موقع ويب مثل هذا في غضون أسبوعين باستخدام عملية تكرارية ولا يزال مصممًا جيدًا. الميزة التي تتمتع بها عملية التكرار على نهج الشلال هي أنه يمكنك ضبط المتطلبات باستمرار عند الذهاب. يعد تغيير المتطلبات المتكررة حقيقة واقعة ، حيث أن الناس غالباً ما يغيرون رأيهم وإمكانية إنتاج تطبيق عمل بعد كل تكرار يسمح للمرء بالبقاء في مساره حتى يتحدث.

بالطبع ، عندما تقدم مشروعًا إلى عميل ، سيكون تحليلًا كاملاً مع مخططات UML وبعض الشاشات الوهمية مفضلة حتى يكون لديهم فكرة عما تقدمه. هذا هو المكان الذي يأتي فيه UML. بمجرد شرح بعض الاتفاقيات البصرية ، يجب أن يكون الفرد قادرًا على فهم المخططات.

للانتهاء ، إذا كنت في الموقف الذي تحاول تحديد ما يريده العميل ، فمن الجيد أن تكون فكرة جيدة أن تبني استبيانًا تدريجياً يمكنك إحضاره معك. إن إجراء مقابلة مع الشخص هي الطريقة الوحيدة التي يمكنك من خلالها تحديد المفاهيم/الميزات اللازمة حقًا للتطبيق ، ويجب أن تتوقع العودة لتوضيح بعض الجوانب. نصيحة أخرى هي إجراء بعض الأبحاث السريعة على الويب عندما تواجه موضوعًا لا تعرفه.

في مثالك ، سيكون هذا هو الذهاب من خلال أساسيات التشريح. من بين أشياء أخرى ، سيساعدك ذلك على تحديد ما يجب أن يحتويه النموذج وما هو الحبيبي الذي يجب أن يكون عليه (ما هي مجموعة الأعضاء التي يجب مراعاتها؟ ما مدى دقة ذلك؟ مكوناتها مثل الأنسجة ، والخلايا ، والتكوين الكيميائي ، وما إلى ذلك؟).

Answer 2

سواء أكان DDD أم لا ، أوصي بتحديد اللغة في كل مكان (UL) من خلال مقابلة مالك (مالك) المنتج. إن إنشاء اتصال بطريقة ستجعلك أنت ولصحاب المنتجات يتحدثون نفس اللغة ليس فقط مساعدين في التواصل ، ولكن القدرة على مناقشة المشروع بالشروط الشائعة تميل إلى مساعدة نموذج المجال على تعريف نفسه.

لذا ، فإن إجابتي هي في الأساس لمناقشة والاستماع والتعلم. يخدم البرنامج حاجة. إن فهم النموذج من وجهة نظر الخبراء سيضع الأساس الصلب للتطبيق.

Answer 3

أعتقد أن المكان المناسب للبدء سيكون كل ما هو منطقي ومريح. من الأفضل أن تبدأ بحالات الاستخدام ، لأنها تمنحك توجيهًا وأهدافًا واضحة ، وتساعدك على تجنب حالات Yagni. بالنظر إلى أنك يجب أن تحاول تطوير نموذج مجال قوي ، فلا ينبغي أن يكون مهمًا حقًا ، لأن الصورة الكاملة للمجال مهمة.

Answer 4

أود أن أشارك تجربتي في هذا النوع من المواقف. عادة ما أبدأ في كتابة اختبارات ورمز. وحاول تغطية حالة الاستخدام نهاية واحدة إلى النهاية. هذا يعطيني فكرة عادلة بما فيه الكفاية عن المشكلة وفي النهاية لدي شيء يعمل معي والذي يمكنني عرضه على موكلي. في معظم الوقت ، تبني القصص اللاحقة على رأس القصة السابقة ، ولكن يحدث لي أيضًا أن القصص اللاحقة تتطلب تغييرات في النموذج السابق الذي توصلت إليه. لكن هذا لا يؤثر علي لأن لدي بالفعل تغطية اختبار جيدة. وبهذه الطريقة توصلت إلى النموذج الذي يناسب المشكلة الحالية ، وليس النموذج الذي يرسم العالم الحقيقي.

Answer 5

تبدأ بمتطلبات العمل التي يمكن أن تكون رسمية أم لا. إذا تم إضفاء الطابع الرسمي على استخدام مخططات الحالة.

على سبيل المثال ، هنا تستخدم مخططات حالة لتطبيق التجارة الإلكترونية:http://askuml.com/blog/e-commerce/

http://askuml.com/files/2010/07/e-commerce-use-case.jpg http://askuml.com/files/2010/07/e-commerce-use-case2b.jpg

من حالات الاستخدام هذه ، يمكنك استنتاج كيانات الأعمال بشكل طبيعي: المنتج ، فئة المنتج ، عربة التسوق ، ... والتي تبدأ في إعداد الرسوم البيانية للصف.

هذه هي أفضل الممارسات في العديد من المنهجيات ، لكن هذا أيضًا هو مجرد الحس السليم والطبيعي.

Answer 6

اجابة قصيرة

اختر حالة الاستخدام ، ارسم بعض مخطط التعاون (ومخطط الفصل) لتحقيق كائنات المجال المعنية. ركز فقط على تلك الكائنات المشاركة من أجل تحقيق هدف الحالة. اكتب حالة اختبار TDD لتعيين التوقع ونمذجة فصول المجال تدريجياً لتلبية التوقعات. TDD من المفيد للغاية فهم السلوكيات المتوقعة ويساعد على الحصول على نموذج المجال المنظف. سترى نطاقك يتطور تدريجياً مع توقعات TDD.

اجابة طويلة

تجربتي الشخصية مع DDD لم تكن سهلة. كان ذلك لأننا لم يكن لدينا أسس ضرورية في المقام الأول. كان لدى فريقنا العديد من نقاط الضعف في مناطق مختلفة ؛ لم يتم التقاط المتطلبات بشكل صحيح ولم يكن لدينا سوى ممثل عميل لم يكن مفيدًا حقًا (غير مشارك). لم يكن لدينا خطة إصدار مناسبة وكان المطورون نقصًا في المفاهيم الموجهة نحو الكائن وأفضل المبادئ وما إلى ذلك. كانت المشكلة الرئيسية التي واجهناها قضاء الكثير من الوقت في محاولة فهم منطق المجال. لقد رسمنا العديد من الرسوم البيانية للفصل ولم نحصل أبدًا على نموذج النطاق بشكل صحيح ، لذلك توقفنا عن فعل ذلك واكتشفنا الخطأ الذي حدث. كانت المشكلة أننا حاولنا بجد أن نفهم منطق المجال وبدلاً من التواصل الذي قمنا به الافتراضات على المتطلبات. قررنا تغيير نهجنا ، قمنا بتطبيق TDD ، وبدأنا في كتابة السلوك المتوقع وترميز نموذج المجال لتلبية توقعات TDD. في بعض الأحيان تعثرنا في كتابة حالات اختبار TDD لأننا لم نفهم المجال. تحدثنا على الفور إلى ممثل العميل وحاولنا الحصول على مزيد من المدخلات. قمنا بتغيير استراتيجية إطلاقنا ؛ تطبق منهجية رشيقة وإصدارها بشكل متكرر حتى حصلنا على ملاحظات حقيقية من المستخدم النهائي. ومع ذلك ، هناك حاجة لضمان تعيين توقع المستخدم النهائي على المستوى الصحيح. لقد أعيدناها بناءً على ردود الفعل ، وبهذه الطريقة تطور نموذج المجال تدريجياً. بعد ذلك ، طبقنا أنماط التصميم لتحسين قابلية إعادة الاستخدام والصيانة. نقطتي هنا هي أن DDD وحدها لا يمكن أن ينجو ، يجب علينا بناء النظام الإيكولوجي الذي يحتضن المجال ، يجب أن يكون لدى المطورين مفاهيم OOP قوية ويجب أن نقدر اختبار TDD ووحدة. أود أن أقول أن DDD يجلس فوق جميع تقنيات وممارسات OOP.