أنماط المدير والتسليم والوكيل كأداة

يبدأ موضوع أنماط المدير والتسليم والوكيل كأداة من نتيجة عمل محددة: اختيار من يملك الإجابة والسياق. في حالة منظومة دعم بوكيل فرز ومختص فواتير ومختص إرجاع نسمّي وحدة العمل والهوية المخولة والأثر المتوقع.

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

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

قال العميل: «أعدت الجهاز وما زال القسط قائمًا». يتحقق الفرز من رقم الطلب وإيصال الناقل، لكن الفواتير لا تعرف إن أكمل المخزن الفحص. يسأل المدير مختص الإرجاع عن inspection_status وreceived_at فقط. إذا كان الفحص معلقًا، يحفظ حالة انتظار بموعد مراجعة؛ وإذا ثبت، ينقل حقيقة مؤرخة إلى الفواتير لتفسير الرسم. لا يُستنتج رد المال من نبرة رسالة العميل.

في تجربة من 120 حالة وجّه التسليم المبني على الكلمات 96 حالة صحيحة بمتوسط 2.4 انتقال. وجّه المدير باستدعاءات منظمة 108 حالات بمتوسط 1.2، لكنه حذف received_at في خمس خلاصات. الإصلاح ليس تمرير كل المحادثة؛ اجعل وقت الاستلام حقلًا إلزاميًا في قضايا رسوم الإرجاع. يراجع المدقق المالك والسؤال والدليل وقبول التسليم من سجل الانتقال وحده.

جمع طلب واحد سؤالًا عن رسم الإرجاع وتغيير وسيلة الدفع. يملك الإرجاع حقيقة الاستلام والفحص، وتملك الفواتير تفسير الرسم، وتملك خدمة الدفع التغيير الفعلي. يسأل المدير الأول عن inspection_status وreceived_at ثم الثاني عن سبب الرسم وفق هذين الحقلين. لا تمرر تفاصيل البطاقة عبر أي مختص؛ يبدأ فرع تغيير الدفع بتحقق هوية وخدمة أثر مستقلة.

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

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

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

نقارن تصميمين على 120 حالة. التصميم الأول يسلم الحوار كاملًا كلما ظهرت كلمة «فاتورة»؛ حقق توجيهًا صحيحًا في 96 حالة، لكنه صنع متوسط 2.4 انتقال للحالة، واضطر المختص إلى إعادة قراءة 38 رسالة في بعض الرحلات. التصميم الثاني أبقى مديرًا واحدًا وطلب من مختص الفواتير جوابًا منظمًا في الحالات المختلطة؛ حقق 108 توجيهات صحيحة ومتوسط 1.2 انتقال. ظهرت مع ذلك خمس حالات فقد فيها الملخص تاريخ استلام المرتجع. لا نخفي هذا العيب داخل المتوسط؛ نضيف حقل received_at إلى عقد السياق ونجعله إلزاميًا عندما يكون نوع الطلب return_billing. إذا غاب الحقل يتوقف المسار ويطلب قراءة المصدر بدل تخمينه.

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