قبل عام ، قدم مكسيم Arshinov (مارشينوف) عرضًا تقديميًا "التصميم الفوري". تقرير كبير ، المتحدث الكاريزمي ، مواد مفيدة في النهاية. غيّر هذا التقرير فهمي لما كنت أفعله - أي منا لم يحاول تطبيق بنية خطوط الأنابيب بشكل حدسي؟ ثم هناك حلول أنيقة مضروبة في DDD! بدأت هذه رحلتي بصفتي مبشرًا في التصميم الخاص بالمجال.

DotNext 2019 موسكو قريبا. كما هو الحال دائمًا ، ننتظر مراجعة الميزات الجديدة وتبادل الخبرات وأفضل الممارسات والحلول المعمارية - لذلك نحن جميعًا نحب المؤتمرات. في قائمة التقارير يوجد مقال بعنوان "تألق وفقر نموذج الموضوع" الذي لفت انتباهي. اقتباس من الصفحة:

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

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

اختلالات استخدام التصميم الموجه نحو الموضوع

الوضع الحالي لديه بعض التطور التاريخي. دعونا نفكر في مراحل كيف تطورت الحالة.

ترويج

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

الخلل # 1: الربحية

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

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

الاختلال الوظيفي رقم 2: التصميم الفوري الملقب Anemic Model المعروف أيضًا بالموافقة

من الواضح أن مجتمعًا معينًا من المبرمجين يحاول أن يجلب إلى جماهير الممارسات تصميمًا أقل تكلفةً موجهًا للموضوع ، مما يقلل التكاليف ويطبق تقنيات جديدة: RailwayProgramming ، وخطوط الأنابيب ، و Anemic model. ينصح الكثيرون ، وهو أسلوب رائع ، يمكن تدريسه لأي مبرمج: "هنا لديك SeedWorks مع واجهات وتنفيذها وكل شيء سيكون." وهي تعمل! ولكن هذا ليس DDD.

أنت لا تفهم تماما إيفانز.

• من لا يمتدح كلوبستوك؟ ولكن هل يقرأها الجميع؟ لا. نريد أن يكون التبجيل أقل ، ولكن قراءة المزيد من الاجتهاد! (ليسينغ).

ساوضح الان

نموذج فقر الدم هو مضاد

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

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

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

لكنه لا يمكن أن ينتهي مع نهاية عبثية لفكرة DDD.

ضعف # 3 الحياة بعد الأشياء التجارية ويعرف أيضا باسم تعقيد الأدوات.

في ربيع عام 2019 ، أخبرنا Maxim و Wagib عن كيفية عدم ظهور ميزات F # في C # ، حول كيفية جعل النموذج بشكل صحيح في F # أسهل ، حول كيفية عدم انتهاك OOP في الوظيفة. الآن يمكن أن تصدق الجماهير أن DDD لم يكن فقط بأسعار معقولة لطلب الموسيقى ، ولكن ليس لجميع البشر ، ولكن فقط أولئك الذين يعرفون البرمجة الوظيفية.

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

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

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

إن الشيء المثير للاشمئزاز هنا هو الطبيعة الإنسانية البسيطة لموقف الإنجازات - حيث يقدر الناس هذه الإنجازات بحد ذاتها ، دون منحهم نموذجًا وتطبيقًا مطبقًا. وهنا قد تكون القائمة طويلة. لقد أعطانا أينشتاين STO ، GR ، FE ، إنه عالم ممتاز ، لكنه يسأل الشخص العادي عن الحركة النسبية ، الوقت - لا يحتاج إلى أينشتاين ، ولكن في محادثة "ذكية" يمكن للمرء أن يذكر أن كل شيء نسبي. اسأل شخصًا عن Freud ، وهو عالم نفسي ممتاز حقق تقدماً جادًا في العلوم ، ما إذا كان هذا الشخص يستخدم علم النفس ، على سبيل المثال ، لتفسير كابوس الأمس - لن يفعل ذلك ، لكنه سيذكر يومًا ما الجنسانية وعلم النفس للجماهير. ماركس هو الذي صنع العلم من علم الاجتماع والتاريخ ، لكن لا أحد يحتاج إلى اشتراكية علمية ، ولكن يمكن للجميع التحدث عن الضرائب التقدمية والديمقراطية الصادقة. كما أن التصميم الموجه للمشاكل ليس له أي شكل - فقد فتح إريك إيفانز آفاقًا جديدة لنا ، مما يوفر أداة ممتازة لتقليل تعقيد البرامج ، لكن ظاهريًا كيف يمكن استخدام DDD وما يجب فعله غير واضح ، وعمومًا لا يعمل على الإطلاق.

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

أسباب أزمة الاستخدام

مبادئ التصميم الموجه للموضوع مغرية للغاية ومنطقية وشاملة. كل شيء قريب هنا - Agile ، CI ، SOLID ، GRASP - كل التوفيق الذي جاء به المطورون. ومع ذلك ، لا يكفي أن تؤمن DDD ، أو الأعمال التجارية ، أو الخبرة. كثير من الناس من المجتمع ، فقط من المطورين من شركات تكامل ومكاتب الاستعانة بمصادر خارجية ، لديهم بصمة قيم الأعمال في عملهم ، وبكل رغبات لا يمكنهم تجربة الأساليب والممارسات الرائدة ، لأن سعر هذه التجربة والخطأ غير مدرج في قائمة الأسعار - إنه نهائي مادي تمامًا.

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

يؤدي

يمكن دائمًا تجربة DDD إذا كنت تصف كائنات حقيقية. يمكن تطبيق هذا النهج في PHP ، وفي VBA ، و 1 C (ويطبق المطورون). تكمن مشكلة تطبيق النهج في مستوى التواصل بين الناس ، والتكنولوجيا من الأرجح أن تساعد. التواصل ، حاول ، تعليم الآخرين! تعزيز Softskills ، التضامن ، وحدة الهدف. DDD هو مجرد تقنية العمل الجماعي.

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

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

ملاحظة: الغرض من الموضوع هو دعوة للمناقشة. لا يوجد أي هدف لتقليل ميزة أي أعضاء في مجتمع DDD. مع الاحترام ، أعامل جميع الممثلين ، الذين لا يزيلون مشاكل التنمية.