أحداث المجال مقابل أحداث التكامل

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

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

أحداث المجال

ما هذا ؟
وفقًا لمارتن فاولر ، فإن حدث المجال "يجسد ذكرى شيء مثير للاهتمام يؤثر على المجال".

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

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

بمعنى آخر ، فإن إنشاء ميزانية هو جزء من نفس المجال لإخطار العميل بهذه الميزانية ، لكن هذه الإجراءات ليست جزءًا من نفس العملية.

في النهاية ، لدينا "ذاكرة" للميزانية التي تم إنشاؤها والتي تؤثر على "مجال المبيعات" باستخدام هذه الذاكرة لإرسال الميزانية إلى العميل.

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

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

ما هي فوائده؟
يمكنني استنباط بعض الفوائد:

  • فصل المخاوف ، مما يجعل عمليات الصيانة أسهل ؛
  • نموذج جيد لرمزك ، باستخدام مفهوم اللغة في كل مكان.
  • قابلية الاختبار ، لأن العملية لا تعتمد على الآخر.

أحداث التكامل

ما هذا ؟
حدث ملتزم حدث في الماضي ضمن سياق محدد والذي قد يكون مثيرًا للنطاقات الأخرى أو التطبيقات أو خدمات الجهات الخارجية.

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

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

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

ماذا عن تصميم التطبيق؟
لا يركز هذا السيناريو على تصميم التطبيق المحدد ولكن النظام بأكمله. عندما نتعامل مع الأنظمة الموزعة ، يمكننا التفكير في وجود تطبيقين منفصلين: المبيعات والتسويق.

ينبعث تطبيق المبيعات من حدث "تم إنشاؤه في الميزانية" ، ومن ثم يتفاعل تطبيق التسويق مع هذا الحدث بإرسال إرسال التسويق.

ما هي فوائده؟

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

افكار اخيرة

هذه المفاهيم تزيد من جودة برامجك ، لكن عليك أن تكون معقولاً أثناء تصميم النظام.

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

هذه المقالة متاحة أيضًا باللغة البرتغالية.