یک هسته، چندین اپ: پلتفرم بانکداری whitelabel چطور کار می‌کند
پلتفرم بانکداری whitelabel یعنی یک هستهٔ بانکداری با فرانت‌اند قابل‌تعویض. هسته بخشی است که باید دقیقاً درست کار کند: دفتر کل دوطرفه، حساب‌های مشتری، KYC و آنبوردینگ، صدور و پردازش کارت، ریل‌های کریپتو و استیبل‌کوین، و کنسول اپراتور که پشت همهٔ این‌ها کار می‌کند. اپ بخشی است که مشتری می‌بیند: نام، رنگ‌ها، شکل صفحه‌ها و مجموعه‌ای از قابلیت‌ها که فعال می‌کند. whitelabel یعنی یک هسته بتواند چهره‌های متفاوت داشته باشد، بی‌آنکه زیر هر کدام از نو ساخته شود. یک هسته، چندین اپ.
ساده بگوییم، این ادعایی است دربارهٔ اینکه درزها کجا قرار دارند. هر چه به پول مربوط است مشترک است و یک بار حسابرسی و تطبیق می‌شود؛ هر چه به مشتری مربوط است به‌ازای هر تننت پیکربندی می‌شود. مهندسیِ مهم همین است که این مرز صادق بماند: فرانت‌اند آزادانه فرق کند و هسته‌ای که زیر آن است هرگز فورک نشود. این کالبدشکافی نشان می‌دهد این مرز چطور کشیده می‌شود و چرا کشیدنش با توکن‌های طراحی از کشیدنش با فورک بهتر است.
آنچه هرگز تغییر نمی‌کند: هسته
از نیمه‌ای شروع کنیم که اجازهٔ خلاقیت ندارد. یک انتقال همیشه به یک شکل ثبت می‌شود، چه اپ اسمش را ارسال بگذارد، چه پرداخت و چه واریز: دو ثبت روی دفتر کل دوطرفه، و هیچ‌چیز هرگز حذف نمی‌شود. دفتر کل فقط اضافه می‌کند، پس بازپرداخت یک ثبت متقابل است که به ثبت اصلی ارجاع دارد، نه پاک‌کردن آن. حساب‌ها، موجودی‌ها و بلوکه‌های مجوز اینجا زندگی می‌کنند. KYC و آنبوردینگ، صدور و تسویهٔ کارت و ریل‌های کریپتو و استیبل‌کوین هم همین‌طور. پشت همه‌شان یک کنسول اپراتور هست که در آن هر اقدام دارای دسترسی ویژه نیازمند ذکر دلیل است و در لاگ حسابرسی ثبت می‌شود.
از هر کدام دقیقاً یکی وجود دارد و نکته همین است. تسویه، تطبیق و انطباق درست‌کردنشان سخت و اشتباهشان پرهزینه است، پس یک بار ساخته می‌شوند و هر اپ نتیجه را به ارث می‌برد. وقتی یک تننت مشتری‌ای را آنبورد می‌کند، سطح KYC که هسته تعیین می‌کند همراه آن مشتری وارد کنسول می‌شود، مهم نیست مدارک با صفحه‌های کدام اپ دریافت شده است. هسته نمی‌داند و برایش مهم نیست که اپ بالایی چه نامی دارد؛ حساب‌ها و ثبت‌ها را می‌بیند، نه برندها را.
آنچه تغییر می‌کند: زبان طراحی، معماری اطلاعات، ترکیب قابلیت‌ها
هر چیزی بالای هسته آزادانه تغییر می‌کند، در سه محور. اول زبان طراحی: رنگ، تایپوگرافی، شعاع گوشه‌ها، فاصله‌گذاری و حرکت، یعنی دستور زبان بصری برند. دوم معماری اطلاعات: چه چیزی در صفحهٔ اصلی باشد، جریان‌ها چه نام و ترتیبی داشته باشند، کدام اقدام یک تپ فاصله دارد و کدام سه تپ. سوم ترکیب قابلیت‌ها: اصلاً کدام ماژول‌ها روشن باشند. یک اپ انتقال ساده و یک سوپر‌اپ پرجزئیات می‌توانند روی یک هستهٔ یکسان اجرا شوند و حتی یک صفحه هم مشترک نداشته باشند.
صفحهٔ محصول در /products/pay پنج مسیر عملی را مرور می‌کند و بهتر است آن‌ها را نمونه‌هایی از بی‌نهایت امکان بدانید، نه منویی پنج‌گزینه‌ای. Halcyon یک صرافی تمیز است: کم‌حرف، با تعداد صفحهٔ کم و معامله در مرکز توجه. Lumen یک سوپر‌اپ است که پول در دل گفت‌وگو جابه‌جا می‌شود و پرداخت در چت، اشتراک‌ها و earn صفحهٔ اصلی را با هم تقسیم می‌کنند. Fern با انتقال‌ها شروع می‌شود: ابتدا واریز گروهی و تبدیل ارز مبتنی بر قاعده. Volt یک ساخت تیره بر پایهٔ استیبل‌کوین است با مرتب‌ساز حقوق و کارت‌های تیمی. Meridian چندارزی است: حساب EUR در کنار USDC، موجودی سفر به GBP و یک حساب BTC که پاداش کارت در آن می‌نشیند. پنج برند، پنج معماری اطلاعات، پنج ترکیب قابلیت، و زیر همه‌شان یک دفتر کل، یک KYC و یک پردازشگر کارت.
هیچ‌کدام از این‌ها به این معنا نیست که محصول پنج اپ است. این پنج مسیر، جهت‌هایی هستند که همان خط تولید می‌تواند طی کند؛ عددی که اهمیت دارد پنج نیست، بلکه تعداد تننت‌هایی است که آنبورد می‌کنید. هر کدام گواهی است بر اینکه فرانت‌اند می‌تواند تا شکل صفحهٔ اصلی فرق کند، بی‌آنکه هسته‌ای که زیر آن است متوجه شود.
هسته بخشی است که اجازهٔ ابداع دوباره‌اش را ندارید؛ اپ بخشی است که اجازهٔ محدود کردنش را ندارید. پلتفرم whitelabel یعنی انضباطِ هم‌زمان درست نگه‌داشتن هر دو جمله.
چرا تم‌سازی در سطح توکن از فورک کردن کدبیس بهتر است
برای اینکه یک محصول شبیه چند محصول به نظر برسد دو راه هست. راه بدیهی فورک است: کدبیس را برای هر مشتری کپی کن، ظاهرش را عوض کن و تحویل بده. این فقط برای یک نسخه جواب می‌دهد. بعد از آن، هر رفع باگ و هر تغییر مقرراتی باید N بار روی N نسخهٔ در حال واگرایی اعمال شود، نسخه‌ها از هم عقب می‌افتند و سطح امنیتی که باید دربارهٔ آن فکر کنید به تعداد مشتری‌ها ضرب می‌شود. فورک یک سیستم را که می‌شناسید به چند سیستم ناشناخته تبدیل می‌کند.
تم‌سازی در سطح توکن این را وارونه می‌کند. یک کدبیس وجود دارد. یک برند مجموعه‌ای از مقادیر است: توکن‌های رنگ، تایپوگرافی، شعاع و فاصله‌گذاری، یک پیکربندی کامپوننت‌ها و مجموعه‌ای از فیچرفلگ‌ها که در زمان بیلد به یک اپ برندشده تبدیل می‌شود. با تغییر یک توکن، همهٔ صفحه‌هایی که آن را می‌خوانند با هم عوض می‌شوند، چون هیچ‌چیز مقداری را که باید از توکن بیاید هاردکد نمی‌کند. رفع یک مشکل در جریان انتقال هم یک‌جا برای همهٔ تننت‌ها منتشر می‌شود، چون فقط یک جریان انتقال برای رفع وجود دارد. برندها در پیکربندی فرق دارند، نه در سورس.
جایگاه سیستم طراحی
توکن‌ها ایده‌ای کلی نیستند؛ یک محصول تحویل‌شده‌اند. Protocore Design System (در /products/pds) شامل 144 توکن طراحی و 889 کلاس کاربردی است: واژگانی که همهٔ اپ‌ها با آن تم می‌شوند. این سیستم dark-first و توکن‌محور است، به‌طور پیش‌فرض radius صفر دارد و همین مجموعه توکن برای وب، .NET و نیتیو تولید می‌شود؛ پس رنگی که یک بار تعریف شود در صفحهٔ React، کنسول دسکتاپ و بیلد موبایل نیتیو یکی است. برند هر تننت به‌صورت override روی همین واژگان بیان می‌شود، برای همین تغییر ظاهر اپ یک تغییر پیکربندی است، نه بازنویسی.
همین باعث می‌شود فرانت‌اند واقعاً آزاد باشد، نه آزاد در چارچوب یک قالب. چون زبان طراحی در توکن‌ها و کلاس‌های کاربردی قرار دارد و نه در استایل‌شیت‌های یک‌بارمصرف، طراح می‌تواند تننت را خیلی از ساخت مرجع دور کند، با پالت، تایپوگرافی، تراکم و ریتم خودش، بی‌آنکه به هسته دست بزند یا اپ را فورک کند. رنگ‌آمیزی عمیق است، اما باز هم فقط رنگ‌آمیزی است؛ لوله‌کشی زیر آن مشترک است.
اپ یک پیکربندی است، نه یک بیلد
ترکیب قابلیت‌ها از همین قاعده پیروی می‌کند. هر ماژول (پرداخت در چت، earn، کریپتو، کارت‌ها، اشتراک‌ها، کارت‌های تیمی، معرفی دوستان) برای هر تننت یک کلید است و فلگ را می‌شود ابتدا برای بخشی از کاربران فعال کرد و بعد گسترش داد. اپراتورها آن‌ها را از پنل پیکربندی عوض می‌کنند، نه با دیپلوی. پس فرق اپ ساده‌ای برای انتقال با یک سوپر‌اپ کامل، دو پروژه نیست؛ دو پیکربندی از یک پروژه است. اپ مرجعی که هر تننت از آن شروع می‌کند، یک بیلد خنثی با برند Protocore است که کل منو را دارد؛ هر whitelabel همان بیلد است با توکن‌های overrideشده و ماژول‌هایی که روشن یا خاموش شده‌اند.
مرز صادقانه
«یک هسته، چندین اپ» فقط وقتی ارزش این ساز و کار را دارد که واقعاً چند اپ داشته باشید، یا یک اپ که می‌خواهید در طول زمان ظاهر، چیدمان و دامنه‌اش را عوض کنید، بی‌آنکه هر بار بانک را از نو بسازید. اگر یک اپ ثابت می‌سازید که هرگز برند دومی نخواهد داشت، پلتفرم whitelabel لازم ندارید؛ یک اپ لازم دارید. جایی که ارزشش را نشان می‌دهد همان موردی است که برایش ساخته شده: پلتفرمی که تننت‌به‌تننت محصولات بانکی برندشده بالا می‌آورد، هر کدام آشکارا مال خودش و هیچ‌کدام فورک نیست. کالبدشکافی کامل، شامل پنج مسیر، اپ مرجع و کنسول اپراتور پشت آن‌ها، در /products/pay است و سیستم طراحی زیرین در /products/pds.
سیستمی برای ساختن دارید؟
مسئله را بگویید. با یک معماری و یک برنامه برمی‌گردیم.