المشكلة مُؤطَّرة كهندسة.
سوق الحجز ليست كتالوجاً مع checkout. إنها نظام حجز تُحكم صحته في لحظتين — لحظة تأكيد الحجز، ولحظة وصول المستهلك فيزيائياً. بين هاتين اللحظتين، يجب الاحتفاظ بالمخزون، وإبلاغ المشغّل، واستعادته عند الإلغاء، ومصالحته مقابل المال الذي تحرّك. كل واحدة من هذه التحولات عدائية.
الانضباط الهندسي هنا هو آلات حالة الحجز تحت ثلاث دلالات قطاعية غير متجانسة وثلاثة أدوار عميل. الفنادق تحجز ليالي. المطاعم تحجز نوافذ زمنية. التأجير يحجز أصولاً مؤرَّخة. كل قطاع له طبولوجيا توفره الخاصة، وسطح إلغائه الخاص، وأوضاع فشله — لكن مجال الحجز يجب أن يكون نموذجاً واحداً ليكون النظام قابلاً للتشغيل.
موقف سيملوب من مراجعة المعمارية: توحيد آلة حالة الحجز، وعزل القواعد الخاصة بكل قطاع خلف واجهة نظيفة، وعدم السماح أبداً للتباين القطاعي بالتسرب إلى كونسول المشغّل أو مسار التسوية المالية.
نظام حجز واحد. ثلاثة أدوار عميل.
عميل المستهلك — سطح بحث-وحجز حيث تدفق الحجز مُدرك للقطاع لكن لغة المجال تحته متطابقة عبر القطاعات. انضباط لغة قوي: كل تاريخ، عملة، رقم، ومنطقة زمنية مُمتلَكة من قِبل اللغة، لا مُخصَّصة.
عميل المشغّل — كونسول محدَّد الأدوار لجانب العرض. تقويمات التوفر، قواعد التسعير، محتوى القائمة والحجوزات الواردة هي كائنات من الدرجة الأولى. هُندس للمشغّلين غير التقنيين الذين يعملون تحت ضغط زمني.
عميل المنصة — كونسول عمليات المنصة لإعداد المزوّدين، وتنسيق القوائم، وحل النزاعات، وتوليد تقارير التسوية. دور المنصة لا يلمس أبداً مسارات الكتابة للمستهلك أو المشغّل. هذه الحدود مُطبَّقة على مستوى الخدمة، لا على مستوى الواجهة.
مجال الحجز — آلة حالة واحدة بانتقالات محددة: inquiry → held → confirmed → fulfilled أو cancelled أو refunded. كل انتقال يُصدر حدثاً يستهلكه خط أنابيب التسوية المالية وخط أنابيب الإشعار بشكل مستقل. لا يُسمح لكود عمل بكتابة حالة حجز بالتحوير المباشر؛ الانتقالات تمر عبر واجهة المجال.
تجريد الدفع — واجهة بوابة دفع تعزل المجال عن أي معالج محدد. المنصة تتحدث إلى عقد دفع داخلي؛ المعالجات الخرسانية تعيش خلف محوّل. تبديل معالج — أو إضافة ثانٍ لسوق جديد — لا يلمس منطق الحجز.
تجريد الإشعار — واجهة مراسلة صادرة على نفس النمط: المجال يُصدر أحداثاً، طبقة الإشعار تقرر قناة التسليم والتنسيق. المجال لا يعرف كيف يصل التأكيد إلى المستهلك.
مُركَّزة على المجال، معزولة عن الموردين، مكتملة اللغة.
مجال حجز واحد. تجميع واحد، آلة حالة واحدة، مسار تدقيق واحد. السلوك الخاص بالقطاع يعيش في كائنات سياسة تُنفّذ واجهة حجز مشتركة، لا في قواعد كود متوازية. هذا القرار المركزي الذي يجعل السوق قابلة للتشغيل.
حدود دور على مستوى الخدمة. مسارات كود المستهلك والمشغّل والمنصة تتشارك نفس البيانات لكن ليس نفس قدرة الكتابة. التفويض يُطبَّق على مستوى الخدمة — الواجهة لا تقرر ما يمكن لمستخدم فعله؛ تكتشف ما تسمح به الخدمة.
عقد دفع processor-agnostic. مجال الحجز يُصدر أحداث تحريك أموال مقابل عقد داخلي. أي معالج يطلبه السوق يجلس خلف ذلك العقد كمحوّل. التوسع الإقليمي لا يعني إعادة كتابة محرك الحجز؛ يعني تنفيذ محوّل واحد.
اللغة كمواطن من الدرجة الأولى. العربية RTL، الفرنسية LTR، الإنجليزية LTR — التطبيق ليس قاعدة كود إنجليزية مُترجَمة. معلومات اللغة تتدفق عبر كل طبقة.
سطح SEO ثابت، سطح حجز ديناميكي. الصفحات العامة تُولَّد ثابتة في وقت البناء لصحة SEO وتسليم edge. تدفق الحجز ديناميكي، مُصادَق، ومعزول عن خط أنابيب SEO.
بنية قراءة وكتابة منفصلة. قراءات المستهلك والمشغّل والمنصة تتوسع على مستويات مختلفة. كتابات الحجز تمر عبر عقد single-writer لتبقى انتقالات الحالة حتمية تحت حمل متزامن.
ما جعل هذا صعباً، وكيف حلّيناه.
- 01
توحيد ثلاث دلالات حجز دون السماح بتسربها
حجز فندق وحجز مطعم يبدوان كنفس الكائن من بعيد وهما كائنان مختلفان عن قرب. الإغراء هو بناء ثلاثة نماذج حجز ولصقها في الواجهة. يُنتج ذلك ثلاث قواعد كود متباينة ومسار تسوية مالية لا يثق به أحد. بنينا تجميع حجز واحد مع كائنات سياسة خاصة بكل قطاع — جميعها تُنفّذ نفس الواجهة.
- 02
انتقالات حالة تحت حمل حجز متزامن
مستهلكان يمكن أن يحاولا الاحتفاظ بآخر غرفة متاحة في نفس الميلي ثانية. انتقالات الحالة ثلاثية الأطراف أصعب: مستهلك يبدأ، المشغّل يؤكد، معالج دفع يُقر، والنظام يجب أن يقبل أو يرفض التسلسل كله كانتقال واحد.
- 03
صحة اللغة في كل طبقة، ليس فقط الترجمة
العربية RTL ليست ميزة ترجمة — إنها انضباط layout وتنسيق يلمس كل مسار rendering. نوافذ المطاعم الزمنية يجب أن تعرض بصيغة 12 أو 24 ساعة صحيحة محلياً. إقامات الفنادق يجب أن تُعرَض في التقويم الذي يتعرف عليه المستهلك.
- 04
انضباط المحوّل على الدفع والمراسلة
المنصة يجب أن تسوّي الأموال وترسل الإشعارات. الإغراء هو توصيل معالج محدد ومورد مراسلة محدد مباشرة في كود الحجز لأن ذلك أسرع في اليوم الأول. في اليوم 300، عندما يتغير السوق أو يفشل المورد، تكلفة هذا الاختصار إعادة كتابة.
ما تم تسليمه في الإنتاج، وماذا غيّر.
- 01
ثلاث قطاعات حجز — إقامات ليلية، حجوزات بمواعيد، تأجير أصول مؤرَّخة — تعمل على مجال حجز واحد دون انجراف سلوكي ملحوظ بينها.
- 02
ثلاثة أدوار عميل (مستهلك، مشغّل، منصة) تعمل على تفويض مستوى الخدمة دون مسار تسرب صلاحيات بينها.
- 03
سطح منتج ثلاثي اللغة كامل مع انضباط لغة مُطبَّق في كل طبقة rendering.
- 04
تكاملات دفع ومراسلة خلف عقود داخلية ليكون التوسع الإقليمي أو استبدال المورد تغييراً لمحوّل، لا إعادة كتابة مركزية.
- 05
سطح SEO ثابت منشور عند edge مع خط حجز ديناميكي منفصل — نظام الحجز لا يُنازَع أبداً من قبل ترافيك crawl محركات البحث.
- 06
أول منصة حجز مُدمَجة تشغيلية في السوق — فئة منتج لم تكن موجودة قبل هذا النظام.
ما يسأله المشترون التقنيون والمؤسسون عن هذا المشروع.
01لماذا مجال حجز واحد بدلاً من واحد لكل قطاع؟+
لأن سوقاً تُشغّل ثلاثة نماذج حجز متوازية تُشغّل أيضاً ثلاثة أنظمة تسوية متوازية، وثلاثة مسارات إلغاء متوازية، وثلاثة كونسولات تشغيلية متوازية. هذا الشكل لا يُميَّز عن ثلاثة منتجات منفصلة تتصادف في مشاركة شعار.
02كيف تتعاملون مع خطر الاعتماد على معالج دفع واحد؟+
لا نعتمد على أي معالج محدد. مجال الحجز يتحدث إلى عقد دفع داخلي. أي معالج يطلبه السوق يجلس خلف ذلك العقد كمحوّل. تبديل المعالجات — أو إضافة ثانٍ لبلد جديد — هو تغيير على مستوى المحوّل، لا إعادة كتابة مركزية.
03كيف تكون المنصة قابلة للدفاع تحت حمل حجز متزامن؟+
دلالات single-writer على حدود الحجز، سجل أحداث append-only لانتقالات الحالة، مفاتيح idempotent على كل side-effect وارد. مستهلكان يتسابقان على آخر فتحة متاحة يُنتجان بالضبط حجزاً واحداً مؤكداً ورفضاً واحداً — لا holds مزدوجة، ولا charges مزدوجة، ولا حجز شبحي.
04هل دعم اللغة يمتد إلى ما بعد الترجمة؟+
نعم. العربية RTL هي انضباط layout وتنسيق يلمس كل مسار rendering — تقويم، تنسيق رقمي، عملة، منطقة زمنية، ترتيب، rendering أخطاء تحقق. نعامل اللغة كمعامل من الدرجة الأولى على كل استدعاء format، ليس كتبديل عام.
05هل يمكن لهذه المعمارية الانتقال لأسواق أو قطاعات أخرى؟+
نعم. الشكل الهندسي — مجال حجز واحد، ثلاثة أدوار عميل، خدمات خارجية معزولة بمحوّل، تسوية event-driven، rendering locale-first — هو كيف نبني أسواقاً متعددة البائعين عبر أي قطاع.