چه وقت جدا کردن یک سرویس، کار تیم را سخت‌تر می‌کند؟

دربارهٔ این قسمت

با مثال سفارش و کوپن یک فروشگاه فرضی، هزینه‌های جداسازی سرویس را می‌سنجیم و سه سؤال برای انتخاب بین ماژول داخلی و سرویس مستقل مطرح می‌کنیم.

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