وين الزبون يبطل يكون ثمنية زبائن

الحل المعتاد هو وظيفة مزامنة، وهي آلة كامل هدفها يوافق بين كذبتين. تخدم حتى جهة تتبدل وقت التشغيل، وعندها عندك كذبة ثالثة وتذكرة دعم.

iKoneكت ماشي مدمج مع العائلة. هو فيها. نفس الدخول، نفس الحساب، نفس المنصة تحت — يعني سجل الزبون ما يحتاجش يتصالح بين المنتجات، لأن فيه واحد فقط.

شنو كاتعني «في الجهتين» بالضبط

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

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

ملاحظة من البناء: الجزء الصعب في التكامل تقريبا عمره ما هو الإرسال. هو الاتفاق على شنو هو الحاجة — واش «شخص» في منتج هو «عميل محتمل» في آخر و«زبون» في ثالث. كون عائلة واحدة يعني هذي المناقشة توقعت مرة، داخليا، وما ولاتش مشكلة ديالكم.

حساب واحد، وطريق واحد للخروج منه

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