سأخبرك في هذه المقالة ، باستخدام تطور مشروعي كمثال ، تاريخ الانتقال ورؤية برمجة العقود.
في البداية أردت تسمية المقالة - "برمجة العقود" ، حيث أن النهج المستخدم هو تقسيم كل منطق الأعمال إلى عقود بيانات وخدمة عملاء باستخدام هذه العقود والتفاعل مع بعضهم البعض من خلال هياكل البيانات هذه ، بحيث تتم معالجة الهيكل بنجاح في خدمات مختلفة.
شيء سأصفه بلغتي.
بدأت قصة انتقالي إلى برمجة العقود بحقيقة أن لديّ مشروعًا قديمًا متضخمًا له مجموعة كبيرة من الوظائف المختلفة في نفس مجال الأعمال. زائد ، كل هذا كان لا يزال multithreading والتخصيص لمختلف العملاء. على وجه التحديد ، كان مجال العمل هو تبادل الوثائق الإلكترونية ذات الصلة قانونًا بين نظام المحاسبة والملفات والخدمات السحابية.
في عملية تطوير النظام ، ظهرت متطلبات تجارية جديدة ونتيجة لذلك ، تم تطوير المشروع وتعقيده بسرعة بسبب الوظائف الجديدة ، مما أدى في مرحلة ما إلى وضع بدأت فيه بنية المشروع تشبه العديد من التطبيقات المنفصلة ذات الوظائف المرتبطة. تم تنفيذ هذه الوظيفة فقط ، وليس من العناصر الشائعة ، ولكن من هياكل متشابهة ولكن تم تنفيذها بشكل مختلف في التجميعات ومساحات الأسماء المختلفة.
بصريا ، يمكن تمثيل مثل هذه العمارة على أنها عدة قطاعات من الوظائف
كانت السمة المميزة لمثل هذه البنية هي أنه في حالة ظهور بعض المتطلبات أو الأخطاء الإضافية ، عندئذٍ كان مطلوبًا تنفيذ هذه المهمة في جميع "الوحدات الوظيفية" للنظام ، وليس في منطقة واحدة. ومن السمات المميزة الأخرى وجود عدد كبير من شركات البناء في المشروع ، مما يؤدي إلى هذا التقسيم الرأسي لمنطقة الأعمال. يقوم المطور بتطبيق خوارزميات جديدة لمتطلبات العمل الجديدة في رمز البناة ، مما يؤدي إلى ظهور كيانات جديدة ذات هياكل مختلفة لنفس كائن الأعمال. من المسلم به ، أن هذا النهج يمكن اعتباره أكثر توجهاً للكائنات من نهج الكود البسيط الذي يحتوي على كود السباغيتي. وبالتالي ، إذا رأيت عددًا كبيرًا من البناة في مشاريعك ، فإن الانتقال إلى نهج الاتصال سيبسط الدعم ويسرع عملية تطوير مشروعك.
مرة واحدة ، في الشركة ، واجهنا حقيقة أن العميل الذي كنا ننفذ معه بدأ في التعبير عن أن النظام الذي طورته غالبًا ما ينتج عنه أخطاء. لم أستطع المجادلة مع هذا ، على الرغم من أن الأخطاء ظهرت بشكل دوري ، لكن تم إصلاحها وكان بعض العملاء قاموا بتثبيت النظام واستخدامه. يجب أن أقول شكراً لك على أن العميل كان ضارًا وصعب الإرضاء ، واختبر نظامنا بعناية فائقة خلال فترة التنفيذ.
أنا أيضًا لا أحب حقيقة أنه لم يكن لدي ما يكفي من الوقت للتنمية والدعم ، على الرغم من الكثير من الجهود ، وفي وقت ما لم يكن لدي أي فكرة عما يمكن أن يحسن النظام ويجعله أكثر استقرارًا.
جاء القرار فجأة وبشكل غير متوقع.
لقد فهمت جيدًا أن نفس كائنات الأعمال يتم تنفيذها بشكل مختلف في وحدات مختلفة من النظام - مستندات من أنواع مختلفة ، إيصالات ، عمال ، عملاء خدمة ، عملاء قاعدة بيانات ، عملاء ملف لديهم القدرة على تخزين المستندات بتنسيقات مختلفة (تخصيص لعملاء مختلفين ؛) )
تم تنفيذ جزء من المنطق في الكيانات ، مما حال دون استخدام نفس الكيانات في خوارزميات مختلفة.
بعد ذلك قررت - كان من الضروري إنشاء شيء يشبه مُنشئ واحد مع التفاصيل التي يمكن من خلالها تجميع جميع الخوارزميات المنفذة في النظام. وهو أمر منطقي ، لأنه يقلل من عدد الطبقات المماثلة ، ويبسط الدعم.
قررت تقسيم بدقة "الكون" من طلبي إلى
- عقود البيانات - هياكل البيانات التي تحتوي على وتستخدم فقط لتخزين البيانات
وثائق
المغلفات
المبالغ المستلمة
FL
...
- عملاء - خدمات - أكتب بشكل محدد أن العملاء هم من الخدمات ، لأنه عند تطبيق كل نظام تفاعل في مجال الأعمال ، قمت بتمثيله كمغلف على هذا النظام ، حيث تم تنفيذ أساليب العمل بعقود التاريخ. وإلى جانب حقيقة أن هذه الفئات عبارة عن مغلفات على الخدمات ، فقد احتوت أيضًا على المنطق الملزم والتحويلات والتحويلات اللازمة لتبسيط منطق العمل
بالإضافة إلى ذلك ، تشبث قطع الاشجار لهؤلاء العملاء. سمح لك ذلك بالعثور بسرعة على نقطة الخطأ من خلال السجل. (في المستقبل ، اختفت الكثير من المكالمات عندما بدأ المستخدمون أنفسهم ، من خلال السجلات ، يفهمون أين أخطأوا - نظام الملفات أو الشبكة أو نظام المحاسبة أو خدمة الويب الخاصة بالمشغل)
على سبيل المثال
CloudClient - عميل لخدمة سحابة يتم إرسال المستندات إليها ومعالجتها
- تنزيل
- ارسل
- احصل
- تنزيل
- أوافق
...
FileSystemClient - عميل نظام الملفات
ERPClient - نظام محاسبة العميل
نفذ العملاء جميع الطرق المستخدمة سابقًا في الخوارزميات في جميع الوحدات ، مما أتاح تنفيذ الخوارزميات المنفذة حديثًا بسرعة وسهولة من نفس الأجزاء.
وتخصيص أساليب وظائف مماثلة في العملاء المعنيين أدى إلى مزيد من التخصص وإعادة استخدام الكود.
أصبحت العمارة الآن مخططًا كما في الصورة
لقد خصصت جميع الكائنات الأساسية لمصممي للتجميع بنهاية مجموعة أدوات تطوير البرامج (SDK) ، وأصبح العمل أكثر سهولة وأكثر أهمية. لقد توقف العمل بالفعل عن إنشاء عكازات وحلول مؤقتة ، والآن أصبح الموقف من المشروع من الداخل أكثر خطورة من حقيقة أنني رأيت الآن هامشًا كبيرًا من قابلية تطوير الهندسة المعمارية وقدرتها التنافسية. وذلك لأن هذه الحقيقة زادت بشكل كبير الدافع وفتحت آفاقا مهنية جديدة.
بناءً على SDK الذي تم إنشاؤه ، قمت بتسليمه لتنفيذ طبقة من منطق الأعمال التي تعمل تلقائيًا على تنفيذ مهام العمل مباشرةً. نظرًا لأنه تم إحضار جميع الفروق الدقيقة التقنية إلى الطبقات السفلية الموجودة في العملاء ، فقد تم تبسيط تنفيذ نفس الخوارزميات وبدأت تبدو أكثر متعة.
هذا النهج بسيط ، ويسمح بتبسيط المزيد من التطوير ، وما هو مهم للغاية ، زيادة مرونة الهيكل. نعم ، هذا سوف يتطلب إعادة هيكلة واسعة النطاق. في حالتي ، استغرق الأمر أسبوعين من التطوير في وضع متعصب. ولكن بعد ذلك ، لم أكن تقريبا رمز ، لأن كل شيء يعمل بشكل مستقر.
وبفضل الفصل بين المسؤوليات (SPR) والسجلات ، تمكنت بسرعة من كبح أخطاء خدمات الجهات الخارجية ، مما أدى إلى حدوث أخطاء من جانبي. سابقا ، كان هذا التحليلات المطلوبة التي أكلت وقتا طويلا.
هذا النهج جيد لاستخدامه في طبقات معينة. في الطبقات العليا من التطبيق ، قد يكون نموذج فقر الدم أكثر ملاءمة ، إلا أنه من الأفضل تنفيذ نموذج فقر الدم على أساس نهج تعاقدي.