مقدمة
أود أن أتحدث عن تجربة تطبيق ممارسات DDD على مشروع Ruby on Rails الحالي. في البداية ، كان لدينا مترابط مكتوب لمدة 10 سنوات. كانت الصعوبة الرئيسية للمشروع في العمليات المعقدة إلى حد ما ، والاتصال العالي. تمكنا ليس فقط من تحليل التطبيق إلى خدمات منفصلة ، ولكن أيضًا زيادة إمكانية قراءة الكود بشكل ملحوظ ، وجعل العمليات الموصوفة شفافة.
أصبح حل المشكلات داخل النظام قابلاً للتنبؤ به ، وتوقفنا عن العمل مع الصندوق الأسود ، وفي النهاية ، بدأ النظام نفسه يدفعنا بالحلول.
لتسهيل كل من الإدراك والكتابة ، سيتم تقديم قصة عن المناهج المستخدمة في شكل سلسلة من المقالات. هذا النهج ليس "رصاصة فضية" ، لذلك أود أن أسلط الضوء أولاً على كل جزء من المشاريع التي يمكن أن يناسبها هذا الحل. علاوة على ذلك ، سأتحدث بمزيد من التفصيل عن منهجية DDD وتنفيذ الخدمات الدقيقة لهذا النمط ، وسأصف المجموعات المحتملة من الأنماط المطبقة ، مع الأخذ بعين الاعتبار تنفيذها ، وأعطي في النهاية مثالًا على تنفيذ محدد لخدمة صغيرة واحدة.
مكنز
قاموس المرادفات هو مسرد للمصطلحات المستخدمة لوصف مجال موضوع معين.
جميع التعريفات التي سيتم تقديمها أدناه صحيحة في إطار هذه المقالة. يمكنك تطبيقها على مجال الموضوع الخاص بك إذا وصفوه جيدًا بما فيه الكفاية.
تم حل المشكلة في إطار هذا النهج
النهج الموصوف أدناه لديه تخصص ضيق نوعًا ما ، وقبل كل شيء ، يهدف إلى حل مشكلة محددة. ومع ذلك ، لا يستبعد هذا الاهتمام المحتمل من المتخصصين في المجالات ذات الصلة. لذا ، لدينا المهمة:
تحتاج إلى إعادة كتابة مشروع والحفاظ عليه باستخدام منطق تجاري معقد مكتوب بلغة Ruby on Rails ، بموارد كافية.
لنكتب هذه المهمة بمزيد من التفصيل.
لماذا هناك حاجة لإعادة كتابة المشروع؟
أعتقد أن كل مطور يمكنه الإجابة على هذا السؤال. من الصعب الإجابة بحيث تلبي هذه الإجابة احتياجات عملك.
نستخدم تعريف الأعمال ، كما هو مقبول بشكل عام ، على الرغم من أننا سوف نستثمر في هذا المصطلح مفهومًا أوسع - مؤسسة (شيء تقوم به مجموعة من الناس) ، مهنة (مشغولة).
العمل هو جهد شركة من الناس ، يتم التعبير عنه من خلال العمل الذي يهدف إلى الحصول على فوائد لمجموعة واسعة من الأفراد.
على سبيل المثال:
- تصنع الشركة منتجًا للمستهلكين أو تقدم خدمة.
- يقوم المختبر بتطوير دواء جديد.
- تشارك المدرسة في التدريب.
- يوفر أرشيف المدينة معلومات للمواطنين.
- تسعد ليرا معجبيها بشخصية ممتازة على الشبكة الاجتماعية.
في الحالة الجماعية ، يتم بناء الأعمال حول فكرة تحقيق الربح من خلال تلبية احتياجات عملائها. من أجل زيادة الربح ، من الضروري تلبية الاحتياجات الفعلية للعميل بعدد كبير من الحلول عالية الجودة. توصف هذه الفكرة بأنها المبدأ الأول للبيان الرشيق ، على الرغم من أن الفكرة ليست جديدة. لقد جادل العديد من الفلاسفة في حقيقة أن الاحتياجات هي أساس مجتمعنا. على سبيل المثال ، حاول أفلاطون تبسيط الاحتياجات وإنشاء تصنيفهم. هو الذي يسمي الأشكال الرئيسية للاحتياجات الاقتصادية: الغذاء والملابس والسكن. "التحدي التجاري" هو تلبية الاحتياجات. ويجب أن تزيد الحلول التطبيقية من القدرة التنافسية للأعمال.
القدرة التنافسية - ميزة الأعمال التجارية على الأخرى.
يمنحنا البيان الرشيق أيضًا إشارة إلى أن مرونة المشروع يتم تعزيزها من خلال التميز التقني وجودة التصميم.
ضع في اعتبارك سلسلة توريد القيم على مثال "مشروع ويب نموذجي"
- ر 0 - لدينا فكرة.
- ر 1 قمنا بتنفيذ MVP . هنا نتطرق قليلا:
الحد الأدنى من المنتجات القابلة للتطبيق من MVP - منتج يحتوي على الحد الأدنى من الوظائف ولكنه كاف لإرضاء أول المستهلكين. المهمة الرئيسية هي الحصول على ردود الفعل لتشكيل الفرضيات لمزيد من تطوير المنتج.
تم تعميم المصطلح من قبل ستيف بلانك وإريك ريس. MVP هي أداة فعالة لاختبار فكرة عملك والإجابة عن السؤال الرئيسي "الإقلاع - ألا تقلع؟"
- ر 2 - العودة إلى الجدول. كانت الفكرة ناجحة ، تلقينا ردود فعل إيجابية وتمكنا من تلبية عدد كبير من احتياجات العملاء في الوقت المحدد.
- ر 3 - هذه المرة ، جاء الرضا إلى حد أقل. لقد زدنا عدد الموظفين.
- ر 4 - لقد قدمنا قيمًا أقل.
- ر 5 - إذا لم نبدأ إعادة البيع ، فحينئذٍ يتوقف العمل عن المنافسة.
لماذا يحدث هذا؟ بمرور الوقت ، يتراكم مشروعنا على مستوى عال من الانتروبيا بسبب اتصاله العالي. لنفترض أن لدينا "شركة نموذجية" تتكون من قسم التسويق والتحليل والخدمات اللوجستية والمبيعات والإدارة. المشروع في الوقت الحالي على النحو التالي:
أود أن أحجز على الفور أن الاتصال ليس دائمًا سبب الانتروبيا ، ولكنه ينشأ إذا تم تنفيذ نظام يحتوي على عدد كبير من العمليات التجارية المعقدة.
دائمًا ما يحدث الانتروبيا في التعليمات البرمجية إذا لم يتم تكوين عمليات الأعمال في الشركة بشكل صحيح. ما قد يكون مميزًا لكلا الشركتين الشباب ، اللتين تقعان في بداية طريقهما ، هو أيضًا سمة الشركات الكبيرة ، حيث من المستحيل تنظيم كل شيء في وقت واحد. هذه عملية طبيعية ولا يجب أن نقف في طريقه ، بل نقبلها ونستخدمها. دعنا نعود إلى المخطط الأول ونلقي نظرة عليه من الجانب الآخر:
سيكون التكامل (المنطقة تحت الخط) هو المال المكتسب. سيكسب التطبيق الحقيقي (التطبيق الحقيقي) أكثر من "المثالي" (تطبيق Academin) ، على الأقل حتى بداية الكون - ر 4 . يبدو ذلك جيدًا ، وهذا ما عليك القيام به.
ولكن ماذا تفعل في المستقبل؟ تكرار إعادة البيع إلى اللانهاية أمر مستحيل. في وقت ما ، سيصل حجم قاعدة الكود إلى هذا المستوى بحيث سيكون من الصعب إعادة كتابة "مرة واحدة". عاجلاً أم آجلاً سيكون من الضروري تقسيم المشروع إلى مكونات منفصلة:
نهج واحد لتنفيذ النظم المعقدة هو DDD:
التصميم المستند إلى المجال (DDD) هو نهج لتطوير البرامج لتلبية الاحتياجات المعقدة ، من خلال ربط التنفيذ مع نماذج الأعمال الرئيسية التي هي قيد التطوير المستمر.
DDD هي سلسلة من الممارسات والتعريفات التي سيتم وصفها بمزيد من التفصيل في المقالة التالية. النمط المركزي لهذا النهج هو السياق المحدود ، الذي يتمثل جوهره في أن كل مجال موضوع يتكون من عدة مجموعات من النماذج التي لا يجب أن تتواصل مع العالم الخارجي ، وكذلك النماذج المستخدمة في العالم الخارجي بالاقتران مع سياقات محدودة أخرى. يحتوي كل سياق محدود على واجهة محددة بوضوح حيث يقرر النماذج التي سيتم استخدامها بالاقتران مع سياقات أخرى.
يمكن تنفيذ هذا النمط من خلال مساحة الاسم (مساحة الاسم) ، ومن خلال الخدمات الدقيقة. سنستخدم كلا التطبيقين ، اعتمادًا على مستوى اتصال السياق. الأمر الذي يؤدي في النهاية إلى إنشاء تطبيق مجزأ ومتحلل.
من غير المحتمل أن تعكس الرسوم البيانية أعلاه الصورة الحقيقية ، ولكنها تسمح لك بمقارنة المناهج المختلفة فيما بينها.
دعم المشروع
كجزء من دعم المشروع ، يجب توفير عدد من الأشياء.
- تسليم القيمة : سكروم ، رشيقة ، خدمة العملاء ، التسليم المستمر.
- تخفيض الانتروبيا : DDD ، Micro-service كأحد طرق فصل السياقات ، التوثيق.
- جودة الكود : تصميم مستوى المجال ، TDD ، BDD.
- جودة المنتج : الاختبار اليدوي والآلي ، وتتبع الأخطاء ، وتسجيل الدخول.
- توافر المنتج : أنظمة الازدواجية.
- سرعة المنتج : تحجيم أفقي.
- استبقاء فريق التطوير : نظام التحفيز والانفتاح والصدق.
كما ترى ، يتطلب الحفاظ على نظام معقد كمية كبيرة من الموارد. بادئ ذي بدء ، الموظفين المؤهلين تأهيلا عاليا. قبل استخدام هذه التكنولوجيا أو تلك ، فكر فيما إذا كان لديك الفرصة لتقديم دعمها على المستوى الصحيح.
يجب أن نتذكر أن عتبة الدخول إلى نظام معقد مرتفعة للغاية ، لذلك من المهم توفير التدريب للموظفين. أيضًا ، إذا أردنا العمل بدون إخفاقات ، فيجب ألا يكون لدينا متخصصون "لا يمكن استبدالهم" ، وبالتالي فمن الضروري ضمان إمكانية التبادل الكامل لجميع الأدوار. إذا كان لديك "أخصائي توصيل مستمر" يحلق خارج الفريق ، فأنت بحاجة إلى استبداله. إذا لم يكن بالإمكان توفير الاستبدال ، فلا يستحق إدخال مكدس التكنولوجيا في "الإنتاج" دون تقديم دعم كاف.
هذا ليس عن المتخصصين على نفس المستوى. تتيح لك الحصول على DevOps رائد ومطور معين يكون هذا الموضوع مثيرًا للاهتمام له (ما يسمى "multiclass"). بالنسبة له ، أما بالنسبة لـ "الكمان الثاني" ، فمن المهم أن نفهم أين وكيف نجد أدوات لحل المشكلة. لهذا ، يجب توزيع ما لا يقل عن ربع إجمالي حجم المهام الواردة المتعلقة بالتخصص الجديد. سيتم تنفيذ هذه المهام ببطء ، وستزداد التكاليف ، ولكن هذا في المستقبل سيمنع خطر انقطاع توريد القيم بسبب نقص الموظفين.
يتم وصف مثل هذه الأشياء في متطلبات سكروم ، لا أريد أن أتطرق إليها. الشيء الوحيد الذي أود أن ألفت انتباهك إليه ، ما تحتاج إلى الاستعداد له ، هو التكاليف الكبيرة التي سيتم إنفاقها على دعم مشروعك. إذا لم يكن عملك جاهزًا لذلك ، وبدأت في استخدام العديد من الأدوات باهظة الثمن ، فسوف تدمر عملك.
باختصار
- إذا كنت بحاجة إلى تنفيذ MVP ، فابدأ بـ Ruby On Rails.
- إذا انطلقت MVP وأصبحت الفكرة صحيحة ، فقم بأول عملية إعادة هيكلة ، "خفف" نماذجك بمساعدة الخدمات ، الديكور ، قم بإزالة طبقة التحقق وقاعدة البيانات من النماذج إلى مخاوف منفصلة. كتابة الاختبارات والتوثيق.
- إذا لم يكن لديك مثل هذا المشروع المعقد ويمكنك إزالة الكون عن طريق تحسين النماذج - قم بذلك.
- إذا كان لديك مشروع منطقي وقابل للقراءة ، وتحتاج إلى زيادة إنتاجيته ، بينما يمكن تقسيمه ، على سبيل المثال ، حسب المستخدمين ، ثم استخدم القياس. ولكن لا تحاول تقسيم المشروع إلى خدمات حسب المجال.
- إذا كان لديك نشاط تجاري "معقد" وكنت تبحث عن أداة للاتصال بالإنترنت (لماذا لم تفعل ذلك بعد ؟!) - فكر أيضًا في "حلول المؤسسة" الجاهزة ، على سبيل المثال ، في جافا أو .NET. الممارسات الموصوفة نشأت في مثل هذه الحلول ولديها مجموعة أدوات غنية جاهزة ، مما سيوفر لك المال.
- إذا كان مشروعك على الياقوت ، فلديك طاقم من مبرمجي الياقوت ، والمشروع يحتوي على منطق تجاري معقد ، ويستعد للحمل أو تم تحميله بالفعل ، ونما الانتروبيا كثيرًا لدرجة أنه من الصعب جدًا إعادة كتابته ، ثم يجب عليك التفكير في استخدام منهج DDD والخدمات الصغيرة.
في المرة القادمة أود أن أنظر بمزيد من التفصيل في جوهر نهج DDD وتنفيذ الخدمات الصغيرة.
مصادر الإلهام: