🐴 🖕 🚧 الخدمات الدقيقة أم الأنظمة المعيارية؟ كيف يمكن للعميل اختيار نهج لبنية تكنولوجيا المعلومات للمنتج 📳 🕷️ 🧑🏽

الخدمات المصغرة والأنظمة المعيارية هي أنواع من هندسة حلول تكنولوجيا المعلومات.

عند العمل مع الوحدات النمطية ، فإننا ننتهي من إصدار محاصر لمنتج تكنولوجيا معلومات موجود.

نقصد بالإصدار المعبأ نظامًا مترابطًا ونظامًا جاهزًا مع نواة يتم تسليمها لجميع العملاء بنفس الطريقة "كما هي".

يتكون التحسين من إنشاء وحدات مع وظائف مفقودة.

نحصل على وحدات جديدة عن طريق إعادة استخدام أجزاء متجانسة (وحدات أساسية أو وحدات أخرى).
تتم كتابة منطق الأعمال داخل المونوليث: بالنسبة لبرنامج (تطبيق ، موقع ، بوابة) ، توجد نقطة دخول واحدة ونقطة خروج واحدة.

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

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

فوائد العمارة المعيارية

جميع أنظمة CMS (Bitrix ، Magento ، Drupal ، Hybris ، إلخ.) ، CRM ، ERP ، WMS ، والعديد من الأنظمة الأخرى لديها إصدارات محاصر. إنهم يبيعون جيدًا ويزداد الطلب عليهم.
دعونا نلقي نظرة على تلك الأسباب الموضوعية التي غالبا ما يختار العملاء العمل بها مع بنية معيارية وشراء الحلول المعبأة عن طيب خاطر.

سرعة عالية في التنفيذ

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

بالنسبة للشركات الصغيرة ، يمكن أن تكون هذه الفترة بضعة أيام فقط.
. , enterprise- .
. . , , , .
,

. , .

هناك عوامل ذاتية أخرى يمكن أن تكون مضللة وتؤثر على قرار استخدام الصناديق والوحدات.

1. سباق مصنعي

البرمجيات يقنعون العملاء بحرارة بأن حلهم خارج الصندوق هو الحل الصحيح: لقد تم اختباره لسنوات ، وعصري ، ومؤسسي ، وشعبي ، وتسويقي ... أي مورد: Bitrix ، Magento ، SAP ، Oracle ، OpenCart ، يعمل جانغو وكل شخص آخر بجد على تقنيات التسويق والمبيعات.

2. الاعتقاد الخاطئ حول مدى تعقيد التحسينات:

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

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

إذا كانت شركتك شركة صغيرة وكان البرنامج ليس أصلك الرئيسي ، فمن المرجح أن يناسبك حل محاصر شائع (أو أفضل - حل سحابي).

دعونا نلقي نظرة على المشاكل التي قد تواجهها عند العمل مع بنية معيارية وكيف تساعد الخدمات الصغيرة على تجنب ذلك.

مشاكل الأنظمة المعيارية

المشكلة الرئيسية هي أن جميع الأنظمة المعيارية ليست مصممة لإعادة تعريف الوظائف بشكل جدي. لديهم صندوق ، وحدات جاهزة - من الأفضل استخدامها.

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

المشكلة رقم 1. يصبح جوهر النظام نقطة تباطؤ ، وتصبح النمطية تعقيدًا غير ضروري.

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

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

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

بعد كل التغييرات ، يصبح النظام معقدًا للغاية بحيث سيلزم عدد كبير من الساعات بشكل غير لائق لإضافة التخصيصات التالية.

المشكلة رقم 2. مبدأ التوثيق الذاتي غير معتمد في الأنظمة المعيارية.

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

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

المشكلة رقم 3. زيادة تماسك المدونة - مسار الانحدار: "لقد غيروها هنا ، سقطت"

المشاكل الكلاسيكية للأنظمة المعيارية هي في محاربة الانحدار.

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

تصبح الاختبارات الوظيفية كبيرة مثل لا معنى لها. تعمل لساعات ، حتى في موازاة ذلك.

نعم ، يمكن اختبار واجهة حديثة مثل PWA API- وظيفيا. لكن الاختبارات غالبًا ما تعتمد على استقبال البيانات من الدائرة الخارجية - وبالتالي تبدأ في الشعور إذا كان اختبار SAP وراء البقالة لمدة N أشهر على سبيل المثال ، وأرسل اختبار "1C" بيانات غير صحيحة.

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

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

يجب أن تعترف بأن مثل هذا الموقف مع الانحدار ليس مثل "المؤسسة المستقرة" كما يجب أن يكون في أحلام وأحلام العميل.

المشكلة رقم 4: توصيل الكود وتحديث النظام الأساسي

مشكلة أخرى في اتصال الكود هي صعوبة تحديث النظام الأساسي.

على سبيل المثال ، يحتوي Magento على مليوني سطر من التعليمات البرمجية. أينما نظرنا ، هناك الكثير من التعليمات البرمجية في كل مكان (Akeneo ، Pimcore ، Bitrix). عند إضافة وظائف إلى kernel ، سيكون من الأفضل مراعاة التغييرات في وحداتك المخصصة.

هنا مثال حي لـ Magento.
في نهاية عام 2018 ، تم إصدار نسخة جديدة من منصة Magento 2.3. تمت إضافة Multistores و Elasticsearch إلى إصدار المصدر المفتوح. بالإضافة إلى ذلك ، تم إصلاح الآلاف من الأخطاء في النواة وأضيفت بعض الأشياء الجيدة في OMS.

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

تخيل الآن: كم من الوقت سيتم إنفاقه على مثل هذا التحديث وكيف يمكن اختباره بدون اختبارات التكامل ، والتي يصعب كتابتها؟

ليس من المستغرب أن يتم تحديث النظام الأساسي للكثيرين إما بدون إعادة بناء ، ولكن مع زيادة في الازدواجية ، أو (إذا كان الفريق يريد القيام بكل شيء في فنغ شوي) مع "المغادرة" لفترة طويلة في إعادة الهيكلة واستعادة النظام.

المشكلة رقم 5. عتامة العمليات التجارية

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

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

المشكلة 6. تعقيد تحجيم النظام

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

تحتاج إلى المزيد من الذاكرة والمعالجات ، مما يزيد بشكل كبير من تكلفة الكتلة.

كيف تنقذ الخدمات الصغيرة العملاء من العيوب النمطية للتطوير المعياري. تنظيم الخدمات الصغرى في Camunda و jBPM

Spoiler: يمكن حل المشاكل المذكورة في الفقرة الأخيرة باستخدام BPMS وتنظيم أنظمة الخدمات الصغيرة.

BPMS (نظام إدارة عمليات الأعمال الإنجليزية) هو برنامج لإدارة العمليات التجارية في الشركة. BPMS الشعبية التي نعمل معها هي Camunda و jBPM.

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

كمثال ، نأخذ عملية متكررة - إرسال طلب للتسليم.

بواسطة أي رسالة أو مكالمة مباشرة ، نبدأ معالجة الطلب بعملية اختيار طريقة التسليم. يتم تعيين منطق الاختيار.

ونتيجة لذلك ، العمليات والخدمات والتطوير:

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

سوف نتعرف على المبادئ التي تعمل من خلالها أنظمة إدارة العمليات التجارية.

مبدأ BPMS رقم 1. تصبح التنمية مرئية وعملية

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

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

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

مبدأ BPMS رقم 2. لكل خدمة مدخلات ومخرجات واضحة.

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

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

يشجعك BPMS على الكتابة بشكل أكثر تجريدية. يتم تطوير العملية بدقة ، مع تحديد المدخلات والمخرجات.

مبدأ BPMS رقم 3. تزامن معالجة قائمة الانتظار

تخيل عملية معالجة الطلبات: نحتاج إلى الذهاب إلى مكان ما في السوق ، والتقاط جميع الطلبات الجيدة والبدء في معالجتها.

انظر إلى الرسم التخطيطي (جزء من الرسم التخطيطي). من المقرر هنا أنه كل 10 دقائق نتحقق من جميع طلبات السوق ، ثم ننفذ بالتوازي (كما هو موضح بواسطة "الهامبرغر" الرأسي في أمر العملية) معالجة كل طلب. في حالة النجاح ، انقل جميع البيانات إلى ERP وأكمل المعالجة.

إذا احتجنا فجأة لرفع السجلات لمعالجة طلب معين ، في Camunda أو JBoss أو أي BPMS أخرى ، فسوف نكون قادرين على استعادة جميع البيانات تمامًا ومعرفة أي قائمة انتظار كانت وما هي معلمات الإدخال / الإخراج.

مبدأ BPMS رقم 4. خطأ وتصعيد

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

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

يصعب برمجة جميع هذه الاستثناءات ليس فقط خارج BPMS (على سبيل المثال ، جهاز ضبط الوقت في جهاز ضبط الوقت) ، ولكن أيضًا لفهمها في سياق العملية بأكملها.

مبدأ BPMS رقم 5. اختيار الإجراءات لأحد الأحداث وخيارات المعالجة

إرسال نفس الطلب في التسليم.

في المجموع ، لدينا ثلاثة سيناريوهات:

تم تسليم البضائع كما هو متوقع ؛
لم يتم تسليم البضائع كما هو متوقع ؛
تم فقد العنصر.

مباشرة في BPMS ، يمكننا تحديد إجراء شحن البضائع إلى شركة النقل ونتوقع أحد الأحداث حسب الطلب:

تسليم ناجح (رسائل من عملية تسليم المنتج تفيد بأنه تم تسليم كل شيء) ؛
أو بداية بعض الوقت.

إذا لم يمر الوقت ، فأنت بحاجة إلى بدء خدمة أخرى: تحليل هذا الطلب المحدد مع عامل التشغيل (تحتاج إلى تعيين مهمة له في نظام OMS / CRM لمعرفة مكان الطلب) مع إشعار آخر للعميل.

ولكن إذا تم تسليم الأمر أثناء عملية التحقيق ، فمن الضروري مقاطعة التحقيق وإتمام معالجة الأمر.

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

مبدأ BPMS رقم 6. في Camunda الخاص بك سترى كل السجلات

باستخدام الأحداث وخيار المعالجة الداخلية ، يمكنك:

ترى التسلسل الكامل للأحداث في نافذة واحدة (ما الذي يحدث مع الترتيب ، أي فرع من الاستثناءات التي مر بها ، وما إلى ذلك - من السهل رؤيته) ؛
يمكنك جمع جميع التحليلات ل BI على أساس سجلات BPMS وحدها (دون الحاجة إلى زيادة الخدمات الصغيرة مع أحداث التسجيل).

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

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

الاستنتاجات: مقارنة بين الخدمات الصغيرة والعمارة المعيارية

لكل نوع من أنواع العمارة مزاياه وعيوبه. لا يوجد حل عالمي.

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

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

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

في بداية المشروع:

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

بعد أول 3-4 أشهر من التطوير (هذا هو متوسط تاريخ الإصدار لأول MVP) وما بعده:

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

في الختام ، دعونا نلقي نظرة على كيفية تنسيق الخدمات الصغيرة مع أمثلة محددة.

أمثلة على تصوّر الخدمات

النظر في تنسيق الخدمات باستخدام Camunda. من الصور التالية ، يمكنك تقييم مدى ملاءمة إدارة الخدمات الصغيرة باستخدام BPMS مع منظم. جميع العمليات مرئية والمنطق واضح.

تبدو العمليات التجارية كما يلي:

مثال (طلب ، خدمة توفر):

يمكن ملاحظة أنه في هذا الطلب كان هناك فرع "لا بضائع".

نسخة أخرى من الأمر (ذهبت إلى التجميع):

ذهب الأمر إلى أبعد من ذلك ، ووفقًا لجدول القرار (DMN) ، ذهب إلى فرع المعالجة من قبل مشغل خدمة توصيل معين (Boxberry):

العناية بالعملية المتداخلة:

العملية المتداخلة عملت:

تاريخ العمليات التجارية:

خصائص هذا التصور:

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

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

انظر أيضًا: فيديو حول موضوع "الخدمات الصغيرة أو العمارة المتجانسة: ماذا تختار؟"

الخدمات الدقيقة أم الأنظمة المعيارية؟ كيف يمكن للعميل اختيار نهج لبنية تكنولوجيا المعلومات للمنتج