หนึ่งแกน หลายแอป: แพลตฟอร์มธนาคารแบบ whitelabel ทำงานอย่างไร
แพลตฟอร์มธนาคาร whitelabel คือแกนธนาคารหนึ่งแกนที่มีหน้าบ้านเปลี่ยนได้ แกนคือส่วนที่ต้องถูกต้อง ได้แก่ ledger แบบบัญชีคู่ บัญชีลูกค้า KYC และการ onboarding การออกและประมวลผลบัตร rail คริปโตและสเตเบิลคอยน์ และคอนโซลผู้ดำเนินการที่ทำงานอยู่เบื้องหลังทั้งหมด ส่วนแอปคือสิ่งที่ลูกค้าเห็น ทั้งชื่อ สี รูปทรงของหน้าจอ และชุดฟีเจอร์ที่เปิดใช้ Whitelabel หมายความว่าแกนเดียวสวมได้หลายหน้าโดยไม่ต้องสร้างใหม่ใต้แต่ละหน้า หนึ่งแกน หลายแอป
พูดตรง ๆ นี่คือข้อกล่าวอ้างว่ารอยต่ออยู่ตรงไหน ทุกอย่างที่เกี่ยวกับเงินใช้ร่วมกัน ตรวจสอบ และกระทบยอดครั้งเดียว ทุกอย่างที่เกี่ยวกับลูกค้ากำหนดค่าตาม tenant งานวิศวกรรมที่สำคัญคือรักษาเส้นแบ่งนี้ให้ซื่อตรง ปล่อยให้หน้าบ้านต่างกันได้อย่างอิสระโดยที่แกนด้านล่างไม่เคย fork บทความนี้แกะให้เห็นว่าเส้นแบ่งถูกขีดอย่างไร และทำไมการขีดด้วย design token ดีกว่าการขีดด้วย fork
สิ่งที่ไม่เปลี่ยน: แกน
เริ่มจากครึ่งที่ไม่อนุญาตให้สร้างสรรค์ การโอนเงินลงบัญชีด้วยวิธีเดียวกัน ไม่ว่าแอปจะเรียกว่าส่ง จ่าย หรือ payout คือสองรายการบน ledger แบบบัญชีคู่ และไม่มีอะไรถูกลบ ledger มีแต่เพิ่ม การคืนเงินจึงเป็นรายการหักล้างที่อ้างอิงรายการเดิม ไม่ใช่การลบทิ้ง บัญชี ยอดคงเหลือ และ authorization hold อยู่ที่นี่ KYC และการ onboarding การออกบัตรและการชำระหนี้ รวมถึง rail คริปโตและสเตเบิลคอยน์ก็เช่นกัน เบื้องหลังมีคอนโซลผู้ดำเนินการเดียว ทุกการกระทำที่มีสิทธิ์พิเศษต้องระบุเหตุผลและบันทึกลง audit log
ทุกอย่างนี้มีเพียงหนึ่งเดียว และนั่นคือประเด็น การชำระหนี้ การกระทบยอด และการปฏิบัติตามกฎระเบียบทำให้ถูกต้องได้ยากและแพงถ้าพลาด จึงสร้างครั้งเดียวแล้วให้ทุกแอปได้ผลลัพธ์ไปเลย เมื่อ tenant onboard ลูกค้า ระดับ KYC ที่แกนตัดสินจะตามลูกค้าไปยังคอนโซล ไม่ว่าหน้าจอของแอปใดจะเก็บเอกสาร แกนไม่รู้และไม่สนว่าแอปด้านบนชื่ออะไร มันเห็นบัญชีและรายการบัญชี ไม่ใช่แบรนด์
สิ่งที่เปลี่ยนได้: ภาษาดีไซน์ สถาปัตยกรรมข้อมูล ชุดฟีเจอร์
ทุกอย่างเหนือแกนเปลี่ยนได้อย่างอิสระใน 3 แกน แรกคือภาษาดีไซน์ ได้แก่ สี ตัวอักษร รัศมีมุม ระยะห่าง และการเคลื่อนไหว ซึ่งเป็นไวยากรณ์ภาพของแบรนด์ ที่สองคือสถาปัตยกรรมข้อมูล (IA) อะไรอยู่บนหน้าแรก โฟลว์ถูกตั้งชื่อและเรียงลำดับอย่างไร การกระทำใดอยู่ห่างหนึ่งแตะ และการกระทำใดสามแตะ ที่สามคือชุดฟีเจอร์ คือโมดูลใดเปิดใช้บ้าง แอปโอนเงินเรียบง่ายกับซูเปอร์แอปแน่น ๆ ใช้แกนเดียวกันได้ โดยไม่ใช้หน้าจอร่วมกันเลยสักหน้า
หน้าผลิตภัณฑ์ที่ /products/pay แสดงห้าทิศทางที่ใช้งานจริง ซึ่งควรอ่านเป็นตัวอย่างจากความเป็นไปได้ไม่จำกัด ไม่ใช่เมนูห้าข้อ Halcyon เป็นแพลตฟอร์มแลกเปลี่ยนเรียบสะอาด เน้นความสงบ มีไม่กี่หน้าจอ และให้การเทรดเป็นศูนย์กลาง Lumen เป็นซูเปอร์แอปที่เงินเคลื่อนไหวในบทสนทนา โดย chat payments การสมัครสมาชิก และ earn ใช้หน้าแรกร่วมกัน Fern เปิดด้วยการโอนเงิน โดยมี batch payout และการแปลง FX ตามกฎมาก่อน Volt เป็นบิลด์โทนมืดสำหรับสเตเบิลคอยน์ มีตัวจัดสรรเงินเดือนและบัตรทีม Meridian รองรับหลายสกุลเงิน มีบัญชี EUR คู่กับ USDC ยอดคงเหลือ GBP สำหรับเดินทาง และบัญชี BTC ที่รับรางวัลจากบัตร ห้าแบรนด์ ห้าสถาปัตยกรรมข้อมูล ห้าชุดฟีเจอร์ โดยมี ledger เดียว KYC เดียว และตัวประมวลผลบัตรเดียวอยู่ข้างใต้ทั้งหมด
ทั้งหมดนี้ไม่ได้หมายความว่าผลิตภัณฑ์คือห้าแอป ทั้งห้าคือทิศทางที่ pipeline เดียวกันไปได้ ตัวเลขที่สำคัญไม่ใช่ห้า แต่คือจำนวน tenant ที่คุณ onboard แต่ละรายเป็นหลักฐานว่าหน้าบ้านต่างกันได้ลึกถึงรูปทรงของหน้าแรก โดยที่แกนด้านล่างไม่รู้สึกอะไรเลย
แกนคือส่วนที่คุณห้ามคิดค้นใหม่ แอปคือส่วนที่คุณห้ามจำกัด แพลตฟอร์ม whitelabel คือวินัยในการรักษาให้ทั้งสองประโยคนี้เป็นจริงพร้อมกัน
ทำไม token-level theming ดีกว่าการ fork โค้ดเบส
มีสองวิธีทำให้ผลิตภัณฑ์เดียวดูเหมือนหลายตัว วิธีที่ชัดเจนคือ fork คือคัดลอกโค้ดเบสต่อลูกค้า ปรับสไตล์ แล้วส่งมอบ วิธีนี้ได้ผลแค่หนึ่งรีลีส หลังจากนั้นทุกการแก้บั๊กและทุกการเปลี่ยนแปลงตามกฎระเบียบต้องทำซ้ำ N ครั้งบน N สำเนาที่ค่อย ๆ เพี้ยนไป สำเนาเหล่านั้นไม่ซิงก์กัน และพื้นผิวด้านความปลอดภัยที่คุณต้องดูแลก็เพิ่มตามจำนวนลูกค้า การ fork เปลี่ยนระบบเดียวที่คุณเข้าใจให้กลายเป็นหลายระบบที่คุณไม่เข้าใจ
Token-level theming พลิกกลับด้าน มีโค้ดเบสเดียว แบรนด์คือชุดของค่า ได้แก่ token ของสี ตัวอักษร รัศมีมุม และระยะห่าง การกำหนดค่าคอมโพเนนต์ และชุด feature flag ซึ่งถูก resolve ตอน build เป็นแอปแบรนด์นั้น เปลี่ยน token หนึ่งตัว ทุกหน้าจอที่อ่านค่าก็เปลี่ยนพร้อมกัน เพราะไม่มีอะไรฮาร์ดโค้ดค่าที่ควรมาจาก token แก้โฟลว์การโอนครั้งเดียวก็ส่งถึงทุก tenant พร้อมกัน เพราะมีโฟลว์โอนให้แก้เพียงหนึ่งเดียว แบรนด์ต่างกันที่การกำหนดค่า ไม่ใช่ที่ซอร์สโค้ด
ตำแหน่งของ design system
token ไม่ใช่แนวคิดลอย ๆ แต่เป็นผลงานที่ส่งมอบจริง Protocore Design System — /products/pds — ประกอบด้วย design token 144 ตัวและ utility class 889 รายการ ซึ่งเป็นคลังคำศัพท์ที่ทุกแอปใช้ทำธีม เป็น dark-first ขับเคลื่อนด้วย token และใช้รัศมีมุมศูนย์เป็นค่าเริ่มต้น และชุด token เดียวกันถูกส่งออกสำหรับเว็บ .NET และเนทีฟ สีที่กำหนดครั้งเดียวจึงเป็นสีเดียวกันทั้งในหน้าจอ React คอนโซลเดสก์ท็อป และบิลด์โมบายล์เนทีฟ แบรนด์ของ tenant ถูกแสดงเป็น override บนคลังคำศัพท์นั้น การ re-skin แอปจึงเป็นการเปลี่ยนค่ากำหนด ไม่ใช่การเขียนใหม่
นี่ยังทำให้หน้าบ้านอิสระจริง ไม่ใช่อิสระแค่ภายในเทมเพลต เพราะภาษาดีไซน์อยู่ใน token และ utility class ไม่ใช่สไตล์ชีตเฉพาะกิจ ดีไซเนอร์จึงพา tenant ออกจากบิลด์อ้างอิงไปได้ไกล ทั้งพาเลต ตัวอักษร ความหนาแน่น และจังหวะ โดยไม่แตะแกนและไม่ต้อง fork แอป สีทาไปได้ลึก แต่ก็ยังเป็นแค่สี ท่อด้านล่างใช้ร่วมกัน
แอปคือการกำหนดค่า ไม่ใช่บิลด์
ชุดฟีเจอร์ก็ใช้กฎเดียวกัน ทุกโมดูล ไม่ว่าจะเป็น chat payments, earn, คริปโต, บัตร, การสมัครสมาชิก, บัตรทีม หรือ referral คือสวิตช์ที่เปิดต่อ tenant และ flag สามารถปล่อยให้ผู้ใช้บางส่วนก่อนปล่อยวงกว้าง ผู้ดำเนินการสลับจากแผงตั้งค่า ไม่ต้อง deploy ความต่างระหว่างแอปโอนเงินเปล่า ๆ กับซูเปอร์แอปเต็มรูปแบบจึงไม่ใช่สองโปรเจกต์ แต่คือสองการกำหนดค่าของโปรเจกต์เดียว แอปอ้างอิงที่ทุก tenant เริ่มต้นเป็นบิลด์กลางแบรนด์ Protocore ที่มีเมนูครบทุกอย่าง แต่ละ whitelabel คือบิลด์นั้นที่ override token และเปิดหรือปิดโมดูล
เส้นแบ่งที่พูดกันตรง ๆ
หนึ่งแกน หลายแอป คุ้มกับกลไกก็ต่อเมื่อคุณมีหลายแอปจริง ๆ หรือมีแอปเดียวที่คุณตั้งใจจะ re-skin จัดเรียงใหม่ และปรับขอบเขตตามเวลา โดยไม่ต้องสร้างธนาคารใหม่ทุกรอบ ถ้าคุณส่งมอบแอปเดียวแบบตายตัวที่จะไม่มีวันสวมแบรนด์ที่สอง คุณไม่ต้องการแพลตฟอร์ม whitelabel คุณต้องการแอป มันคุ้มค่าในกรณีที่ถูกสร้างมาเพื่อ คือแพลตฟอร์มที่เปิดผลิตภัณฑ์ธนาคารแบรนด์ตัวเอง tenant แล้ว tenant เล่า แต่ละรายเป็นของตัวเองอย่างเห็นได้ชัด และไม่มีรายใดเป็น fork บทแกะรายละเอียดฉบับเต็ม ทั้งห้าทิศทาง แอปอ้างอิง และคอนโซลผู้ดำเนินการเบื้องหลัง อยู่ที่ /products/pay และ design system ด้านล่างอยู่ที่ /products/pds
มีระบบที่ต้องสร้างไหม
บอกเราว่าปัญหาคืออะไร แล้วเราจะกลับมาพร้อมสถาปัตยกรรมและแผนงาน