مرحبا يا هبر.ذهبت اليوم إلى قناة #school في GoCommunity باللغة الروسية
في سلاك ووجدت
حوارًا مثيرًا للاهتمام هناك . قادني هذا الحوار إلى بعض الأفكار حول كيفية تفسير زملائي لمفهوم
"نموذج المجال" .
كما اتضح ، هناك الكثير من التفسيرات غير الصحيحة أو غير الدقيقة تمامًا ، وأحيانًا غير دقيقة تمامًا لهذا المصطلح ، والتي تشوهه بشكل أساسي. حول هذا الحوار ، ولدت فكرة هذا المقال. التفاصيل تحت خفض.
سؤال عن العمارة.
لذلك ، طرح المطور السؤال التالي في المجتمع:
أخبرني كيف أقوم بإجراء البنية بشكل صحيح ، فلنفترض أنني صنعت قرصًا في قاعدة البيانات ، وطلبت إجراء إصلاحات لإنشاء نموذج خاص بي ، هل يمكنني استخدام هذا النموذج كنموذج مجال في طلبي ، أم أنه من الأفضل إنشاء نموذج مجال خاص بي وجعل مهايئًا يمنحني نموذج نطاقي بالضبط إنشائه من نموذج الإصلاح؟ "
الذي أعطى مبرمج آخر الإجابة التالية:
أبسط هو العمارة مع نموذج فقر الدم. هذا عندما نموذج DB = مجال نموذج = نموذج استجابة API. نموذج المجال الغني هو وحش نادر وعادة ما يتحول إلى فقر الدم. بواسطة فقر الدم هو المقصود هيكل DTO. المجموعة المعتادة من السمات (الحقول) دون طرق. ينحط المنطق إلى مجموعة من الوظائف التي تعمل على مثل dto. يعتبر فاولر في بعض الأحيان أن مثل هذا العمارة هو مضاد للتآكل. ولكن بعد ذلك حل microservice جيد ، إلخ.
بعد قراءة هذا ، أدركت فجأة سبب وجود الكثير من الجدل حول تنظيم طبقة منطق الأعمال ، ولماذا يفشل الكثير من الناس في تطبيق أساليب مثل
الهندسة المعمارية النظيفة ، إلخ. ماذا يعني
"العمارة مع نموذج فقر الدم" ؟
إذا حاولت العثور على مثل هذا المفهوم على الشبكة ، فمن المرجح أنك لن تجده ، لأنه لا توجد مثل هذه البنية. هناك مفهوم
"AnemicDomainModel" ، وإذا انتقلنا إلى نفس فاولر ، اتضح أن هذا هو مجرد
منهج إجرائي لإنشاء بنية تطبيقية (مرحبًا Fortran و ALGOL و COBOL و BASIC و Pascal و C). هذا ، في جوهره ، هو ما يسميه مؤلف الإجابة
"العمارة بنموذج فقر الدم" .
نموذج المجال.
بعد ذلك ، يطرح السؤال التالي: هل يعتبر
"النموذج المصاب بفقر الدم" نموذجًا أساسيًا؟ لا أعتقد ذلك ، وهذا هو السبب.
الحقيقة هي أن نموذج المجال ليس نموذج بيانات ، على عكس
"نموذج DB" أو
"نموذج استجابة API" . يحتوي نموذج المجال
على تعريف محدد للغاية . علاوة على ذلك ، من الخطأ أن تتداخل مع نموذج قاعدة البيانات ، والذي هو في الأساس
نموذج بيانات .
عندما يتعلق الأمر بنموذج المجال ، هذا هو بالضبط النموذج المفاهيمي. وهذا هو مجمل مفاهيم مجال الموضوع والعلاقات بينهما (أي مجمل السلوك والبيانات). بشكل عام ، الميزة الرئيسية التي تميز نموذجًا واحدًا عن موضوع ما عن الأخرى هي بالتحديد مجموعة من قواعد العمل.
نعم ، يمكن للنموذج المفاهيمي العمل مع البيانات التي يتم تقديمها في أشكال مختلفة (بيانات من قاعدة البيانات أو استجابات واجهة برمجة التطبيقات) ، ولكن جوهر هذا لن يتغير ،
فالسلوك له أهمية قصوى . نقوم بتمرير المدخلات إلى النموذج للحصول على ناتج محدد. يتم تحقيق هذه النتيجة من خلال تطبيق منطق العمل داخل النموذج (بمعنى آخر ، تطبيق قواعد العمل). أجد هنا تشبيهًا للنماذج الرياضية ونمذجة العمليات التكنولوجية (سنوات الطلاب مرحباً).
ما هو محفوف استبدال المفاهيم؟
عند استدعاء هياكل البيانات
"نموذج المجال" ، فأنت حر أو لا تحل محل المفاهيم. هذا يؤدي إلى حقيقة أن منطق الأعمال في كثير من الأحيان ينتشر في جميع أنحاء التطبيق. في الواقع ، فإن نموذج مجال الموضوع في هذه الحالة هو مجموعة من اللطاخات للغاية من الوظائف التي تعمل مع هياكل البيانات.
في حالة تطوير تطبيقات متوسطة وكبيرة ، يؤدي سوء فهم أو مزج هذه المفاهيم ، كقاعدة عامة ، إلى عدد من المشكلات والأسئلة الموجودة بالفعل عند بدء تطوير النظام ، ناهيك عن الدعم طويل الأجل. من بينها ، على سبيل المثال ، هناك أسئلة شائعة مثل:
- "- أين التحقق من صحة البيانات؟"
- "- كيفية تجنب التبعيات الدورية؟"
- "- هل" هذا "منطق العمل بشكل عام؟"
- "- وأين نحافظ على منطق العمل؟"
- إلخ
علاوة على ذلك ، إذا كان لديك CRUD بسيط ، أي أساسا واجهة لقاعدة البيانات ، لن يكون هناك على الأرجح أي مشاكل. إذا كنت تكتب مكتبة على مستوى البنية التحتية (على سبيل المثال ، للعمل مع شبكة أو باستخدام نفس قاعدة البيانات) ، يجب ألا تكون هناك أيضًا مشكلات. ذلك لأن هناك RFC وجميع "قواعد العمل" كانت واضحة منذ فترة طويلة ، وكان المنطق واضحًا منذ فترة طويلة. يمكنك كتابة برنامج إجرائي بسيط ، وسيكون كل شيء على ما يرام.
إذا عدنا إلى حقيقة أن الحوار حول نماذج المجال قد نشأ في مجتمع Go ، أود أن أقول ذلك. نظرًا لحقيقة أن Go هي لغة متعددة النماذج وتدعم عددًا من أنجح مفاهيم OOP (Composition، Interfaces) ، لا تتجاهلها عند نمذجة مجال وتكتب الكود بشكل حصري بأسلوب إجرائي ، كما لو كنت تعمل مع BASIC أو C.
عند تفسير مفهوم "نموذج المجال" بشكل صحيح ، يصبح من الواضح تمامًا لماذا من المعتاد غالبًا فصل منطق العمل في طبقة منفصلة. يصبح من الواضح أيضًا كيف يمكنك تحديد هذه الطبقة نفسها وتطبيق Clean Architecture أو أي صيغة أخرى لها. من خلال عزل طبقة منفصلة ، نقوم بشكل أساسي بإنشاء مكتبة تنفذ النموذج المفاهيمي في شكل رمز البرنامج. نتيجةً لذلك ، يتم تغليف منطق العمل في إطار هذه المكتبة ، ولا يتم نشره في جميع أنحاء التطبيق (كما هو الحال مع النهج الإجرائي الخالص).
بطبيعة الحال ، فإن فهم هذه المفاهيم لن يخلصك من أخطاء التصميم ، ولن يجعلك مطورًا مثاليًا أو مهندس أنظمة ، ولن يعلمك أن تفعل كل شيء بشكل صحيح في المرة الأولى. هنا ، ليس فقط النظرية مهمة ، ولكن أيضًا الممارسة. ومع ذلك ، بمجرد فهمك الصحيح للمفاهيم وتفسير التعاريف ، ستصبح العديد من الأشياء أكثر وضوحًا وبساطة بالنسبة لك.
لتلخيص.
- ليس من الصحيح تسمية "البيانات" بنموذج مجال.
- نموذج المجال هو نموذج مفاهيمي يتضمن كلا من السلوك والبيانات. يمكن تغليفها في طبقة منفصلة ، أو يمكن نشرها في جميع أنحاء التطبيق.
- "الهندسة المعمارية مع نموذج فقر الدم" ليست أكثر من نهج إجرائي لإنشاء بنية التطبيق التي يتم نشر نموذج المجال في جميع أنحاء التطبيق
إيلاء الاهتمام للتعريفات ، ودراستها أعمق من مجرد قراءة قطريا. في كثير من الأحيان نحن كسول وننتزع المعلومات على شكل قطع ، وبعد ذلك يحدث تشويه بالتأكيد. لا تنسَ أن تعود وتلتقط أشياء تبدو واضحة لك لفترة طويلة ، وأرجع دائمًا إلى المصادر واتصل بأسمائها بأسمائها.
جيد للجميع! شكرا لاهتمامكم
PS. سأكون سعيدًا بالاستماع إلى النقد البناء ، وكذلك رؤيتك حول ماهية "نموذج المجال". الإشارات إلى المصدر هي موضع ترحيب.
محدث: هذه المقالة ليست محاولة لتفسير مفهوم "نموذج المجال" بحرية ولوضع في هذا المفهوم معنى واحد أعرفه. أريد أن أنقل هذا: لقد تم استثمار المعنى في هذا المفهوم منذ فترة طويلة ، وهو موصوف بالتفصيل في الكتب والمقالات في ComputerScience. المقال عبارة عن محاولة للتواصل مع الزملاء حول أهمية التصور الصحيح لهذه المفاهيم ذاتها دون تشويه معانيها (هذا أمر مهم لأنه في الممارسة العملية سيسمح لك بكتابة كود أكثر معنى).
UPD2: أنا لست مهندسًا نظريًا للمؤسسات. أنا مطور الممارسة نفسه كما أنت. أنا أكتب الكود كل يوم وأتحدث عن هذه الأشياء من أجل تحسين الكود الخاص بي ، والعملاء أكثر سعادة. إذا ، في رأيك ، شوهت المعنى الأصلي ، وشاركت الروابط مع المصدر وأوضحت المكان الذي أضعه فيه بشكل غير صحيح ، حتى أتمكن من إصلاحه.
UPD3: لأن يفسر الكثيرون مصطلح "موضوع" بطرق مختلفة ، أعطي بعض الأمثلة على مجالات الموضوع بحيث لا يوجد أي التباس واستبدال المفاهيم. يعتمد موضوع الموضوع دائمًا على المشكلة التي تحلها باستخدام تطوير التطبيق:
- حجز التذاكر (إذا كنت من مطوري أنظمة الحجز)
- الخدمات المصرفية (إذا كنت من مطوري التطبيقات المصرفية)
- أنظمة التشغيل (إذا كنت مطور نظام تشغيل مطور)
- إدارة البنية التحتية السحابية (إذا كنت مطور برامج K8s)
- المحاكاة الافتراضية (إذا كنت مطور Docker)
- مراقبة الأداء (إذا كنت مطور بروميثيوس / جرافانا)