⁧⁩استخدام تحليل المجال لنموذج خدمات مصغرة⁧⁩

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

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

مقدمة

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

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

في هذه المقالة والمقالة التالية، سنستعرض الخطوات التالية، وتطبيقها على تطبيق تسليم الطائرات بدون طيار:

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

2. بعدها، قم بتحديد السياقات المحددة للمجال. يحتوي كل سياق حدود على نموذج مجال يمثل نطاق فرعي معين للتطبيق الأكبر.

3. ضمن سياق محدد، قم بتطبيق أنماط التصميم التكتيكي الذي يعتمد على المجال لتحديد الكيانات والمجموعات وخدمات المجال.

4. استخدم النتائج من الخطوة السابقة لتحديد الخدمات المصغرة في التطبيق الخاص بك.

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

ملاحظة

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

السيناريو: تسليم الطائرة بدون طيار

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

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

تحليل المجالات

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

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

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

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

مثال: تطبيق تسليم الطائرات بدون طيار

بعد بعض تحليل المجال الأولي، جاء فريق Fabrikam ومعهم مخطط تقريبي يصور مجال تسليم الطائرات بدون طيار.

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

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

ملاحظة

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

تحديد السياقات المحددة

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

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

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

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

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

في كتاب التصميم المستند إلى المجال، يصف إريك إيفانز عدة أنماط للحفاظ على تكامل نموذج المجال عندما يتفاعل مع سياق آخر محدد. أحد المبادئ الرئيسية للخدمات المصغرة يتمثل في أن الخدمات تتواصل من خلال واجهات برمجة التطبيقات المحددة جيداً. يتوافق هذا الأسلوب مع نمطين يستدعيهما إيفانز وهما «خدمة المضيف المفتوح» و«اللغة المنشورة». فكرة Open Host Service هي أن النظام الفرعي يحدد بروتوكولاً رسمياً (API) للأنظمة الفرعية الأخرى للاتصال به. توسع اللغة المنشورة هذه الفكرة عن طريق نشر واجهة برمجة التطبيقات في شكل يمكن للفرق الأخرى استخدامه لكتابة العملاء. في المقالة تصميم واجهات برمجة التطبيقات للخدمات المصغرة، نناقش استخدام مواصفات OpenAPI (المعروفة سابقاً باسم Swagger) لتحديد أوصاف الواجهة غير الدقيقة للغة لواجهات برمجة تطبيقات REST، المعبر عنها بتنسيق JSON أو YAML.

لبقية هذه الرحلة، سنركز على سياق الشحن المحدد.

الخطوات التالية

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

التصميم التكتيكي المستند إلى المجالات

الموارد ذات الصلة

• نمط بنية الخدمات الصغيرة
• ⁧⁩صمم تصميم خدمات مصغرة⁧⁩
• حدود الخدمة المصغرة للهوية
• تحديد خيار حساب Azure للخدمات المصغرة