قرارداد رویداد؛ زبان مشترک فروشگاه و بازاریابی

قبل از برنامه‌نویسی چه بنویسیم؟

نام رویداد، تولیدکننده، شناسهٔ یکتا، زمان وقوع و نسخهٔ ساختار را مشخص کنید. «سفارش ساخته شد» را از «پرداخت تأیید شد» جدا نگه دارید. برای هر فیلد، نوع داده، اجباری‌بودن و معنای مقدار خالی را توضیح دهید. قالب مشترکی مانند CloudEvents می‌تواند در یکسان‌سازی پوشش رویداد کمک کند؛ اما معنی تجاری داده را تیم شما باید تعریف کند.

سناریوی عملی

فروشگاه رویداد پرداخت را با شناسهٔ سفارش می‌فرستد. سامانهٔ مشتری‌مداری آن را به پرونده متصل می‌کند و بخش بازاریابی فقط در صورت مجازبودن ارتباط، پیگیری مرتبط می‌سازد. پیام بانکی به‌تنهایی جای تأیید معتبر پرداخت را نمی‌گیرد.

آزمون پذیرش

رویداد تکراری، فیلد حذف‌شده و نسخهٔ ناشناخته را آزمایش کنید. اگر دریافت‌کننده نتواند رویداد را بفهمد، باید خطای قابل پیگیری بدهد؛ نه اینکه با حدس، پیامک ارسال کند.

نمونهٔ قرارداد برای یک فروشگاه

فرض کنید هدف، ثبت تاریخچهٔ خرید و پیشنهاد یک پیگیری مرتبط پس از تحویل است. برای رسیدن به این هدف، رویداد سفارش نباید صرفاً نام و موبایل داشته باشد. شناسهٔ ثابت سفارش، وضعیت معتبر، زمان وقوع، مبلغ با واحد مشخص و مرجع مشتری لازم‌اند. رضایت تبلیغاتی هم نباید از وجود شماره نتیجه گرفته شود؛ آن را از مرجع مربوط بخوانید.

سه تصمیم را قبل از اتصال نهایی کنید: اگر شماره خالی بود چه می‌شود؟ اگر مبلغ اصلاح شد کدام نسخه معتبر است؟ اگر سفارش لغو شد کدام اقدام‌های آینده متوقف می‌شوند؟ پاسخ این سؤال‌ها باید در قرارداد و آزمون دیده شود، نه فقط در گفت‌وگوی شفاهی دو برنامه‌نویس.

تحویل به مسئول بازاریابی

یک رکورد آزمایشی را از منبع تا مقصد دنبال کنید. مسئول بازاریابی باید بتواند ببیند رویداد دریافت شده، مخاطب واجد شرایط بوده و پیش‌نویس کدام اقدام ساخته شده است. موفقیت انتقال داده را از موفقیت کمپین جدا گزارش کنید. اگر داده رسیده ولی قانون فعال نیست، این وضعیت خطای شبکه نیست؛ باید به‌عنوان اجرا‌نشدن شرط توضیح داده شود.

در پایان، مسئول نگهداری قرارداد را تعیین کنید. تغییر فیلد منبع باید پیش از انتشار به مصرف‌کننده اطلاع داده شود. فایل نمونهٔ معتبر و نامعتبر، همراه نسخهٔ قرارداد، هزینهٔ پشتیبانی اتصال را پایین می‌آورد چون دو طرف دربارهٔ یک نمونهٔ روشن صحبت می‌کنند.