Platform / Architecture
สถาปัตยกรรมที่ทำให้ทีมพัฒนาเริ่มเร็ว ส่งมอบไว และควบคุมมาตรฐานได้
Gumon Platform ถูกออกแบบเพื่อแก้ปัญหาโครงสร้างซ้ำซ้อนที่เกิดขึ้นในทุกโครงการ โดยทำให้ทีมเริ่มจากมาตรฐานตั้งต้นที่พร้อมใช้งานและขยายต่อได้ในระยะยาว
Architecture reference นี้ใช้เพื่อจัดแนวทางคิดร่วมกันระหว่างทีม ไม่ได้บังคับรูปแบบ implementation เดียว แต่ช่วยลดความคลาดเคลื่อนของการส่งมอบ
Layer
Application Layer
รองรับงานธุรกิจและประสบการณ์ผู้ใช้งาน โดยออกแบบให้ปรับเปลี่ยนได้โดยไม่กระทบระบบทั้งหมด
Layer
API Service Layer
กำหนดสัญญาการเชื่อมต่อและมาตรฐานการสื่อสารระหว่างบริการ เพื่อให้ทีมทำงานร่วมกันได้อย่างคาดการณ์ได้
Layer
Data Stream Layer
รองรับการประมวลผลข้อมูลต่อเนื่อง งานแบบ asynchronous และการติดตามสถานะระบบแบบเรียลไทม์
Core Services
องค์ประกอบหลักที่ทีมใช้งานซ้ำได้ทันที
- - Gumon Core สำหรับโครงสร้างระบบตั้งต้น
- - Auth / Access Control / Profile สำหรับการยืนยันตัวตนและสิทธิ์การใช้งาน
- - Notification / Schedule / Storage สำหรับบริการพื้นฐานที่ใช้ร่วมกัน
- - CLI commands สำหรับ bootstrap, configuration, operations และ extension
Platform Principles
หลักการออกแบบที่ทำให้ระบบขยายได้โดยไม่เสียเสถียรภาพ
- - แกนแพลตฟอร์มแบบเปิดที่ใช้งานได้จริงและตรวจสอบได้
- - มาตรฐานเดียวกันทั้งทีมพัฒนา ทีมปฏิบัติการ และทีมส่งมอบ
- - ออกแบบเพื่อรองรับการเติบโตโดยลดงานตั้งค่าซ้ำ
- - เอกสารและแนวปฏิบัติเป็นส่วนหนึ่งของผลิตภัณฑ์ ไม่ใช่ภาคผนวก
High-Level Architecture
แต่ละชั้นมีอะไรอยู่ข้างในบ้าง
ภาพสถาปัตยกรรมด้านบนบอกว่ามีกี่ชั้นและเชื่อมกันอย่างไร ส่วนหัวข้อนี้ลงรายละเอียดอีกขั้นว่าแต่ละชั้นประกอบด้วยอะไร ทำหน้าที่อะไร และทีมธุรกิจกับทีมพัฒนาได้อะไรกลับไป
Cloud Server Zone
Data Stream Layer
Event Base
เป็นชั้นที่ทำให้ระบบต่าง ๆ เห็นข้อมูลตรงกันด้วยการส่งเหตุการณ์ (event) ต่อกัน แทนการให้แต่ละระบบไปอ่านและเขียนฐานข้อมูลของกันและกันโดยตรง
องค์ประกอบในชั้นนี้
- - Event streaming — กระแสข้อมูลที่บันทึกและส่งต่อทุกเหตุการณ์ในระบบอย่างต่อเนื่อง
- - Data pipelines — เส้นทางแปลงและส่งต่อข้อมูลระหว่างระบบ
- - Message brokers — คิวกลางที่รับประกันว่าข้อมูลหรือชุดคำสั่งจะไม่สูญหายระหว่างทาง
- - Data synchronization — ทำให้ข้อมูลชุดเดียวกันตรงกันข้ามระบบ
ผลที่ได้
เพิ่มระบบใหม่เข้ามาได้โดยไม่ต้องรื้อระบบที่รันอยู่แล้ว เพราะทุกอย่างคุยกันผ่านเหตุการณ์ ไม่ใช่การต่อตรงเข้าฐานข้อมูล
Cloud Server Zone
API Service Layer
Ready to use
เป็นชั้นของบริการเชิงธุรกิจที่ทำไว้แล้วและเปิดใช้งานผ่าน API ทีมจึงหยิบมาประกอบเป็นระบบใหม่ ไม่ต้องเขียนงานพื้นฐานเดิมซ้ำทุกโครงการ
องค์ประกอบในชั้นนี้
- - Point of Sale (POS) — งานขายหน้าร้านและการรับชำระ
- - Customer Relationship Management (CRM) — ข้อมูลลูกค้าและการติดตามความสัมพันธ์
- - Content Delivery System (CDS) — การกระจายเนื้อหาไปยังปลายทาง
- - Content Management System (CMS) — การจัดการเนื้อหาและสิทธิ์การแก้ไข
- - Inventory Management System (IMS) — สต็อกและการเคลื่อนไหวของสินค้า
- - Production Order System (PO) — คำสั่งผลิตและการติดตามสถานะ
- - Human Resource System (HRS) — ข้อมูลบุคลากรและกระบวนการที่เกี่ยวข้อง
- - Case Management System (CM) — การจัดการเคส เรื่องร้องเรียน และงานที่ต้องติดตามจนจบ
- - Booking Management System (BMS) — การจองและตารางทรัพยากร
ผลที่ได้
โครงการใหม่เริ่มจากบริการที่ทำงานได้จริงอยู่แล้ว ไม่ได้เริ่มจากศูนย์ เวลาส่วนใหญ่จึงไปอยู่ที่โจทย์เฉพาะของลูกค้าแทนงานโครงสร้างซ้ำ ๆ
Client Zone
Application Layer
แอปพลิเคชันปลายทาง
เป็นชั้นของแอปพลิเคชันปลายทางที่ส่งมอบให้ผู้ใช้ แต่ละแอปเลือกเรียกเฉพาะบริการที่ตัวเองต้องใช้จากชั้น API เท่านั้น
องค์ประกอบในชั้นนี้
- - E-Commerce Platform — เว็บและแอปสำหรับงานขายออนไลน์
- - E-Learning Platform — ระบบเรียนรู้ออนไลน์
- - Factory ERP — งานบริหารจัดการในโรงงาน
- - Call Center App — งานรับเรื่องและติดตามเคส รวมช่องทาง LINE
- - Hotel Management App — งานจองและบริหารห้องพัก
- - Hospital App — งานบริการผู้ป่วยบนมือถือ
ผลที่ได้
แพลตฟอร์มข้างล่างเป็นชุดเดียวกัน แต่ผลิตภัณฑ์ข้างบนต่างกันได้ตามธุรกิจ และเปลี่ยนหน้าตาแอปได้โดยไม่กระทบบริการที่อยู่ข้างหลัง
องค์ประกอบที่ใช้ร่วมกันทุกชั้น
Identity & Access
Auth / Access Control / Profile — การยืนยันตัวตนและสิทธิ์การใช้งานชุดเดียวกันทั้งแพลตฟอร์ม ไม่ต้องทำระบบล็อกอินใหม่ต่อโครงการ
Shared Services
Notification / Schedule / Storage — บริการพื้นฐานที่ทุกชั้นเรียกใช้ได้ ทั้งการแจ้งเตือน งานตามเวลา และที่เก็บไฟล์
Operations
CLI commands สำหรับการตั้งค่าเริ่มต้น (bootstrap) ปรับแต่ง (configuration) ดูแลระบบ (operations) และส่วนต่อขยาย (extension) — ทำให้การตั้งค่าและดูแลระบบเป็นมาตรฐานเดียวกันทุกทีม
สิ่งที่การแบ่งชั้นแบบนี้รับประกัน
ความสามารถเสริมที่ไม่พร้อม ต้องทำให้ระบบบอกว่าใช้ไม่ได้ ไม่ใช่ทำให้ระบบล่ม — การแยกชั้นจึงไม่ใช่แค่กล่องซ้อนกันในแผนภาพ แต่คือเงื่อนไขที่ทำให้ส่วนที่หยุดทำงานอยู่ในขอบเขตของมันเอง และงานประจำวันเดินต่อได้
รายการในแต่ละชั้นคือชุดอ้างอิงตามภาพสถาปัตยกรรมด้านบน การใช้งานจริงเลือกเฉพาะส่วนที่โจทย์ต้องการ ไม่จำเป็นต้องใช้ครบทุกตัว