أثناء المرحلة الإستراتيجية مبادئ التصميم المستندة إلى المجال (DDD)، تقوم بتعيين مجال الأعمال وتحديد السياقات المحدودة لنماذج المجال الخاص بك. التصميم التكتيكي المعتمد على المجال هو عند تحديدك نماذج المجال مع مزيد من الدقة. يتم تطبيق الأنماط التكتيكية في سياق واحد محدد. في بنية الخدمات المصغرة، نحن مهتمون بشكل خاص بالكيان وأنماط التجميع. سيساعدنا تطبيق هذه الأنماط في تحديد الحدود الطبيعية للخدمات في تطبيقنا (راجع المقالة التالية في هذه السلسلة). كمبدأ عام، يجب ألا تكون الخدمة المصغرة أصغر من مجموعة وألا تكون أكبر من سياق مقيد. أولاً، سنراجع الأنماط التكتيكية. ثم سنطبقها على سياق الشحن المحدود في تطبيق Drone Delivery.
نظرة عامة على الأنماط التكتيكية
يقدم هذا القسم ملخصاً موجزاً لأنماط مبادئ التصميم المستندة إلى المجال (DDD) التكتيكية، لذلك إذا كنت معتاداً على (DDD)، فيمكنك على الأرجح تخطّي هذا القسم. تم وصف الأنماط بمزيد من التفصيل في الفصول من 5 إلى 6 من كتاب إريك إيفانز، وفي كتاب تنفيذ التصميم المستند إلى المجال الذي كتبه فوغن فيرنون.
الكيانات. الكيان هو عنصر له هوية فريدة تستمر بمرور الوقت. على سبيل المثال، في تطبيق مصرفي، سيكون العملاء والحسابات كيانات.
- كيان له معرّف فريد في النظام، يمكن استخدامه للبحث عن الكيان أو استرداده. هذا لا يعني أن المعرف يتعرض دائماً للمستخدمين مباشرةً. يمكن أن يكون معرفاً فريداً (GUID) أو مفتاحاً أساسياً في قاعدة بيانات.
- قد تمتد الهوية عبر سياقات متعددة محدودة، وقد تستمر إلى ما بعد عمر التطبيق. على سبيل المثال، لا ترتبط أرقام الحسابات المصرفية أو المعرفات الصادرة عن جهة حكومية بعمر تطبيق معين.
- قد تتغير سمات الكيان بمرور الوقت. على سبيل المثال، قد يتغير اسم الشخص أو عنوانه، لكنهما لا يزالان نفس الشخص.
- يمكن للكيان أن يحمل مراجع إلى كيانات أخرى.
عناصر القيمة. عنصر القيمة ليس له هوية. يتم تعريفه فقط من خلال قيم سماته. عناصر القيمة هي أيضاً غير قابلة للتغيير. لتحديث عنصر القيمة، تقوم دائماً بإنشاء مثيل جديد لاستبدال العنصر القديم. يمكن أن تحتوي عناصر القيمة على طرق تغلف منطق المجال، ولكن هذه الأساليب يجب ألا يكون لها آثار جانبية على حالة العنصر. تتضمن الأمثلة النموذجية لكائنات القيمة الألوان والتواريخ والأوقات وقيم العملات.
التجميعات. يحدد التجميع حدود التناسق حول كيان واحد أو أكثر. كيان واحد بالضبط في المجموع هو الجذر. يتم إجراء البحث باستخدام معرف الكيان الجذر. أي كيانات أخرى في التجميع هي عناصر تابعة للجذر، وتتم الإشارة إليها من خلال المؤشرات التالية من الجذر.
الغرض من المجموعة هو نمذجة متغيرات العمليات. الأشياء في العالم الحقيقي لديها شبكات معقدة من العلاقات. ينشئ العملاء أوامر، والأوامر تحتوي على منتجات، والمنتجات لديها موردون، وهكذا. إذا كان التطبيق يُعدل العديد من الكائنات ذات الصلة، فكيف يضمن التناسق؟ كيف يمكننا تتبع المتغيرات وفرضها؟
غالباً ما تستخدم التطبيقات التقليدية عمليات قواعد البيانات لفرض الاتساق. ومع ذلك، في التطبيق الموزع، غالباً ما يكون هذا غير ممكن. قد تمتد العملية التجارية الواحدة عبر مخازن بيانات متعددة، أو قد تكون طويلة الأمد، أو قد تتضمن خدمات جهات خارجية. في النهاية، الأمر متروك للتطبيق، وليس طبقة البيانات، لفرض الثوابت المطلوبة للمجال. هذا ما تهدف المجاميع إلى نمذجته.
ملاحظة
قد يتكون التجميع من كيان واحد، من دون كيانات فرعية. ما يجعله إجمالياً هو حدود العملية.
خدمات المجال والتطبيق. في مصطلحات مبادئ التصميم المستندة إلى المجال (DDD)، تعتبر الخدمة عنصراً يقوم بتنفيذ بعض المنطق دون الاحتفاظ بأي حالة. يميز إيفانز بين خدمات المجال، التي تغلف منطق المجال، وخدمات التطبيق، التي توفر وظائف فنية، مثل مصادقة المستخدم أو إرسال رسالة SMS. غالباً ما يتم استخدام خدمات المجال لنمذجة السلوك الذي يشمل عدة كيانات.
ملاحظة
المصطلح خدمة تم تحميله معاني كثيرة جداً في مجال تطوير البرامج. لا يرتبط التعريف هنا بشكل مباشر بالخدمات المصغرة.
أحداث المجال. يمكن استخدام أحداث المجال لإعلام أجزاء أخرى من النظام عند حدوث شيء ما. كما يوحي الاسم، يجب أن تعني أحداث المجال شيئاً داخل المجال. على سبيل المثال، "تم إدراج سجل في جدول" ليس حدثاً في مجال. "تم إلغاء التسليم" هو حدث في مجال. أحداث المجال تكون ذات صلة بشكل خاص في تصميم الخدمات المصغرة. نظراً إلى توزيع الخدمات المصغرة وعدم مشاركة مخازن البيانات، توفر أحداث المجال طريقة للخدمات المصغرة للتنسيق مع بعضها البعض. تناقش المقالة الاتصالات بين الخدمات الرسائل غير المتزامنة بمزيد من التفاصيل.
هناك عدد قليل من أنماط مبادئ التصميم المستندة إلى المجال (DDD) الأخرى غير المدرجة هنا، بما في ذلك المصانع والمستودعات والوحدات النمطية. يمكن أن تكون هذه أنماطاً مفيدة عند تنفيذ خدمة مصغرة، ولكنها أقل صلة عند تصميم الحدود بين الخدمات المصغرة.
توصيل الطلبات باستخدام الدرون (طائرات صغيرة من دون طيار): تطبيق الأنماط
نبدأ بالسيناريوهات التي يجب أن يتعامل معها سياق تقييد الشحن.
- يمكن للعميل أن يطلب من طائرة من دون طيار لالتقاط البضائع من شركة مسجلة في خدمة توصيل الطائرات من دون طيار.
- يقوم المرسل بإنشاء علامة (رمز شريطي أو RFID) لوضعها على العبوة.
- ستلتقط طائرة من دون طيار وتسلم طرداً من موقع المصدر إلى موقع الوجهة.
- عندما يقوم العميل بجدولة التسليم، فإن النظام يوفر الوقت المقدر للوصول بناءً على معلومات المسار وظروف الطقس والبيانات التاريخية.
- عندما تكون الطائرة من دون طيار في رحلة، يمكن للمستخدم تتبع الموقع الحالي وآخر وقت مقدر للوصول.
- حتى تلتقط طائرة من دون طيار الحزمة، يمكن للعميل إلغاء التسليم.
- يتم إخطار العميل عند اكتمال التسليم.
- يمكن للمرسل أن يطلب تأكيد التسليم من العميل، في شكل توقيع أو بصمة الإصبع.
- يمكن للمستخدمين البحث عن محفوظات التسليم المكتمل.
من هذه السيناريوهات، حدد فريق التطوير الكيانات التالية.
- التوصيل
- الحزمة
- طائرة بدون طيار
- الحساب
- التأكيد
- الإعلام
- العلامة
العناصر الأربعة الأولى، التسليم، والحزمة، والطائرة من دون طيار، والحساب، كلها تجمعات تمثل حدود اتساق العمليات. التأكيدات والإشعارات هي كيانات فرعية للتسليمات، والعلامات هي كيانات فرعية للحزم.
تتضمن عناصر الخدمة في هذا التصميم Location وETA وPackageWeight وPackageSize.
للتوضيح، يوجد هنا مخطط لغة التصميم الموحدة (UML) لمجموع التسليم. لاحظ أنه يحتوي على إشارات إلى مجموعات أخرى، بما في ذلك الحساب والحزمة والطائرة من دون طيار.
هناك اثنان من أحداث المجال:
أثناء تحليق طائرة من دون طيار، يرسل كيان Drone أحداث DroneStatus التي تصف موقع الطائرة من دون طيار وحالتها (هل هي في أثناء الطيران، أم هبطت).
يرسل كيان التسليم أحداث DeliveryTracking كلما تغيرت مرحلة التسليم. وهي تشمل DeliveryCreated وDeliveryRescheduled وDeliveryHeadedToDropoff وDeliveryCompleted.
لاحظ أن هذه الأحداث تصف الأشياء ذات المعنى داخل نموذج المجال. يصفون شيئاً عن المجال، ولا يرتبطون ببنية لغة برمجة معينة.
حدد فريق التطوير مجالاً آخر من الوظائف، وهو لا يتناسب بدقة مع أي من الكيانات الموصوفة حتى الآن. يجب أن يقوم جزء من النظام بتنسيق كافة الخطوات المضمنة في جدولة التسليم أو تحديثه. لذلك، أضاف فريق التطوير اثنتين من خدمات المجال إلى التصميم: المجدول الزمني الذي ينسق الخطوات، والمشرف الذي يراقب حالة كل خطوة، في من أجل اكتشاف ما إذا كانت أي خطوات قد فشلت أو انتهت مهلتها. هذا شكل مختلف من نمط Scheduler Agent Supervisor.
الخطوات التالية
الخطوة التالية هي تحديد حدود كل خدمة مصغرة.