جداسازی
مرزی که پایگاه داده نگه می‌دارد، نه کد
هر CRM ادعای چندمستأجری بودن دارد. این ادعا ارزان است؛ آنچه مهم است این است که کدام لایه مرز را نگه داشته. اگر پاسخ این باشد که «برنامه‌ی ما همیشه فیلتر درست را اضافه می‌کند»، آنگاه این تضمین فقط به اندازه‌ی کم‌خواب‌ترین برنامه‌نویسی که تا به حال یک کوئری نوشته معتبر است.
iKonekt از نخستین مهاجرت‌اش چندمستأجری بود، نه اینکه بعداً به آن اضافه شود؛ این شبیه لاف است اما در واقع اعترافی است: افزودن آن بعداً تقریباً غیرممکن است که کسی باورپذیر انجامش دهد، و هر کس تلاش کرده داستانی برای گفتن دارد.
جداسازی در پایگاه داده زندگی می‌کند. هر یک از بیست‌وشش جدول، مستأجری را که به آن تعلق دارد با خود حمل می‌کند و سیاستی که آن را بررسی می‌کند روی هر خواندن و هر نوشتن اجرا می‌شود، کاملاً زیرِ لایه‌ی برنامه. کوئری‌ای که مرز را فراموش کند، مشتریان کس دیگری را برنمی‌گرداند. هیچ چیز برنمی‌گرداند.
امنیت در سطح ردیف، اجباری
نه یک قرارداد، نه یک قاعده‌ی بازبینی کد. پایگاه داده رد می‌کند. هفتاد و دو سیاست، که یکی‌یکی نوشته شده‌اند نه تولیدشده — چون سیاست تولیدشده سیاستی است که هیچ‌کس آن را نخوانده.
کلیدهای ترکیبی
یک سابقه‌ی فرزند، مستأجرِ خود و والدش را با هم، به‌صورت یک جفت، ارجاع می‌دهد. شناسه‌ای سرگردان از شرکت اشتباه حل نمی‌شود — صرفاً ارجاع معتبری نیست.
هیچ مستأجر پیش‌فرضی، هرگز
درخواستی بدون محدوده، بی‌سروصدا به درخواستی برای مستأجر صفر تبدیل نمی‌شود. پیش از رسیدن به پایگاه داده خطا می‌دهد. هیچ حالت «بدون محدوده»ای وجود ندارد که فراموش کنید خاموشش کنید.
باگی که نمی‌توانست خودش را اعلام کند
در حالی که کار جداسازی مستأجرها انجام می‌شد، بیشترِ خطاها پر سر و صدا بودند. به دو شرکت همان دامنهٔ مشتری و بلافاصله اشیای پایگاه داده را بدهید، همراه با کد خطا و ردیابی پشته؛ پیش از ناهار آن را برطرف می‌کنید.
یکی اعتراض نکرد. جدولی از بازنویسی‌های قابل ویرایشِ پرامپت‌ها فقط بر اساس نوعِ پرامپت کلیدگذاری شده بود — نه بر اساس نوع و مستأجر. اگر شرکت دومی نسخهٔ خودش را ویرایش می‌کرد، بی‌سروصدا نسخهٔ شرکت اول را بازنویسی می‌شد، با SQL کاملاً معتبر، بدون خطا، بدون هشدار و بدون آزمونِ شکست‌خورده. این با خواندن تک‌تکِ ایندکس‌های یکتای باقی‌مانده پس از تغییر یک کلید، یکی‌یکی، کشف شد — با این گمان که خطاهای پر سر و صدا رفیق هم دارند.
به این دلیل می‌گوییم که شکل صادقانهٔ این کار همین است. جداسازی ویژگی‌ای نیست که روشنش کنید؛ عادتی است به خواندن بخش‌های خسته‌کنندهٔ شِما، با این فرض که چیزی در آنجا با شما مخالف است.
آزمون‌ها، برای ثبتِ سوابق: ۹۲۳ عدد، اجراشده روی پایگاه داده‌ای که با هر تغییر از صفر بازسازی می‌شود. آن‌ها آنجا نیستند تا ثابت کنند طراحی هوشمندانه است. آن‌ها آنجا هستند چون شیوهٔ شکستِ این طراحی خاص بی‌صدا است و شکست‌های بی‌صدا به کسی نیاز دارند که به جایشان فریاد بزند.
جداسازی چه دستاوردی برای یک انسان عادی دارد
- یک گروه می‌تواند چندین شرکت را از یک نصب اجرا کند و فروشنده‌ای در یکی هرگز مشتریِ دیگری را نمی‌بیند — نه با سیاست، بلکه با ساختار.
- برنامهٔ همکاری، مجموعه‌ای از پرامپت‌ها، ادعای مالکیت مشتری: همه به تفکیک هر شرکت محدود می‌شوند، تا پیکربندی یک مستأجر نتواند مالِ همه شود.
- درخواست حذف داده درون یک مرز پاسخ داده می‌شود نه در میان انبوهی مشترک، و همین است که پاسخ صادقانه را ممکن می‌کند.
- و هیچ‌کس لازم نیست چیزی را به خاطر بسپارد. این همان نکته است — تضمینی که به یادسپاری وابسته باشد، تضمین نیست.
یک خط دیگر که دربارهٔ پایگاه داده نیست
هر سرویس هم‌خانواده اعتبارنامهٔ نام‌دار خودش را دارد. هیچ‌چیز با اعتبارنامهٔ مشترک صحبت نمی‌کند، پس هیچ سرویسی نمی‌تواند تصادفاً جای دیگری عمل کند — انضباطی کوچک که مستقیماً از داشتن یک توکن مشترک و لذت نبردن از آن به دست آمد.
همان غریزهٔ قانون پایگاه داده است. ناممکن‌کردنِ کارِ نادرست به جای نهی‌کردنش، تا توجه شما صرف مشتری‌ها شود نه صرف بیداریِ دائمی.
- 1۲۶ جدولهر یک مستأجر خودش را حمل می‌کند، با اجبارِ بررسی.
- 2۷۲ سیاستتک‌تک نوشته شده‌اند، تا هر کدام را یک انسان خوانده باشد.
- 3۹۴۲ آزمونروی پایگاه داده‌ای که از صفر بازسازی می‌شود، با هر تغییر.
- 4۰ مستأجر پیش‌فرضدرخواستی بدون دامنه هرگز به داده نمی‌رسد.
اندازه‌گیری‌شده روی نسخهٔ زنده
«کاربرد ما همیشه بر اساس شرکت فیلتر می‌کند.»
آن «همیشه» بار سنگینی از جمله را به دوش می‌کشد.
مرز را به درون پایگاه داده پایین بیاورید و بند WHERE فراموش‌شده به جای مشتری‌های دیگری، هیچ برنمی‌گرداند. صفحهٔ خالی شکست بهتری از معرفیِ ناخوشایند است.
برای گروه‌هایی که چند برند را اجرا می‌کنند ←