Stored procedures กับ Visual Workflows: ตรรกะควรอยู่ที่ไหน

ความหมายที่แท้จริงของการตัดสินใจนี้

Business logic คือชุดกฎที่ตัดสินว่าสิ่งใดอนุญาต สิ่งใดเกิดขึ้นต่อไป และระบบควรทำอย่างไรเมื่อผู้คนใช้งาน มันไม่ใช่ข้อมูลเอง แต่มันคือพฤติกรรม: ใครทำอะไรได้ ภายใต้เงื่อนไขใด และมีผลข้างเคียงอะไรบ้าง

ดังนั้นข้อถกเถียงเรื่อง stored procedures vs visual workflows จึงแท้จริงแล้วเกี่ยวกับว่ากฎเหล่านี้ควรอยู่ที่ไหนเพื่อให้เปลี่ยนได้ง่าย แตกหักยาก และชัดเจนสำหรับผู้ที่เป็นเจ้าของกระบวนการ

ทีมส่วนใหญ่ลงท้ายด้วยสาม “ที่อยู่” ของตรรกะ:

• ในฐานข้อมูล (stored procedures, triggers, constraints): กฎรันใกล้กับข้อมูล ซึ่งอาจเร็วและสม่ำเสมอ แต่แก้ไขยากขึ้นสำหรับผู้ที่ไม่เชี่ยวชาญฐานข้อมูล
• ในเวิร์กโฟลว์แบบมองเห็น (ตัวสร้างกระบวนการแบบลากวาง): กฎถูกแสดงเป็นขั้นตอนและการตัดสินใจ ซึ่งมักอ่าน ทบทวน และปรับได้ง่ายเมื่อกระบวนการเปลี่ยน
• ในโค้ดที่กำหนดเอง (เซอร์วิส, แอป, สคริปต์): กฎถูกเขียนเป็นโปรแกรม ซึ่งให้ความยืดหยุ่นสูงสุด แต่การเปลี่ยนแปลงมักต้องอาศัยวินัยทางวิศวกรรมและการทดสอบ

การเลือกมีผลต่อความเร็วในแต่ละวันและการดูแลระยะยาว วางตรรกะผิดที่แล้วคุณจะได้การส่งมอบช้า (ทุกการเปลี่ยนต้องพึ่งคนคนเดียวที่รู้ฐานข้อมูล), บั๊กเพิ่ม (กฎซ้ำในหลายที่), และการดีบักที่เจ็บปวด (ไม่มีใครรู้ว่าทำไมระเบียนถูกปฏิเสธ)

ระบบส่วนใหญ่ประกอบด้วยตรรกะธุรกิจหลายแบบ ตัวอย่างทั่วไปเช่น การตรวจสอบความถูกต้อง (ฟิลด์ที่ต้องมี ขอบเขตที่อนุญาต), การอนุมัติ, การคิดราคาและส่วนลด, การแจ้งเตือน, และกฎการเข้าถึง

วิธีคิดแบบเป็นประโยชน์: ฐานข้อมูลเหมาะกับการรักษาความสมบูรณ์ของข้อมูล เวิร์กโฟลว์แบบมองเห็นเหมาะกับการแสดงกระบวนการธุรกิจ และโค้ดที่กำหนดเองเหมาะเมื่อกฎเฉพาะหรือซับซ้อนเกินกว่าจะโมเดลได้อย่างสะอาด แพลตฟอร์มเช่น AppMaster อยู่ตรงกลางอย่างเข้มแข็ง: คุณสามารถโมเดลข้อมูล แล้วลงมือทำกระบวนการในตรรกะแบบมองเห็นที่อ่านได้โดยไม่กระจัดกระจายกฎไปยังหลายแอป

เกณฑ์: สิ่งที่คุณกำลังเพิ่มประสิทธิภาพเพื่อให้ได้

นี่ไม่ใช่คำถามเรื่องรสนิยม แต่มันคือสิ่งที่คุณพยายามปกป้อง: ข้อมูล ผู้คนที่เปลี่ยนระบบ และความเร็วของการเปลี่ยน

ผลลัพธ์ที่สำคัญ

ตั้งชื่อผลลัพธ์สูงสุดสำหรับโปรเจกต์ของคุณ ทีมส่วนใหญ่บาลานซ์ระหว่างสิ่งเหล่านี้:

• ความถูกต้อง: กฎต้องรันเหมือนเดิมทุกครั้ง แม้ภายใต้ภาระงาน
• ความชัดเจน: คนใหม่ควรเข้าใจสิ่งที่จะเกิดขึ้นโดยไม่ต้องเดา
• ความเร็ว: ตรรกะต้องรันเร็วและใกล้ข้อมูลเมื่อจำเป็น
• การตรวจสอบย้อนหลัง: คุณต้องพิสูจน์ได้ว่าใครเปลี่ยนอะไร และเมื่อไรที่มันรัน
• อัตราการเปลี่ยนแปลง: คุณคาดว่าความต้องการจะเปลี่ยนสัปดาห์ต่อสัปดาห์ ไม่ใช่ปีต่อปี

ยากที่จะทำให้ทั้งห้าข้อนี้เต็มร้อย การดันตรรกะเข้าใกล้ฐานข้อมูลมากขึ้นอาจเพิ่มความถูกต้องและความเร็ว แต่ลดความชัดเจนสำหรับคนที่ไม่คุ้นเคย SQL

ใครจะเปลี่ยนตรรกะ (และบ่อยแค่ไหน)

ซื่อสัตย์กับตัวเองเกี่ยวกับว่าผู้ใดจะเป็นเจ้าของการเปลี่ยนแปลงในแต่ละวัน กฎที่ฝ่ายปฏิบัติการต้องปรับสัปดาห์ละครั้งไม่ควรต้องให้ DBA ดีพลอย stored procedure ทุกครั้ง ในขณะเดียวกัน กฎที่มีผลต่อเงินไม่ควรถูกแก้ไขโดยไม่มีการตรวจสอบ

คิดแบบแรงเสียดทานการเปลี่ยน ถ้าความต้องการเปลี่ยนบ่อย คุณต้องการที่ที่การอัปเดตปลอดภัย มองเห็นได้ และส่งขึ้นใช้งานเร็ว เครื่องมือเวิร์กโฟลว์แบบมองเห็น (เช่น Business Process Editor ของ AppMaster) เหมาะเมื่อเจ้าของธุรกิจและวิศวกรต้องร่วมมือกันบนตรรกะโดยไม่ต้องแกะโค้ดระดับต่ำ หากการเปลี่ยนแปลงเกิดขึ้นไม่บ่อยและกฎมีความสำคัญ การมีแรงเสียดทานสูงขึ้นอาจยอมรับได้

วิธีทดสอบความเป็นเจ้าของแบบเร็ว:

• ใครถูกปลุกตอนตี 2 ถ้ามันพัง?
• คุณต้องแพตช์กฎเร็วแค่ไหน?
• การเปลี่ยนแปลงต้องได้รับอนุมัติหรือต้องมีบันทึกไหม?
• จะมีหลายแอปขึ้นอยู่กับกฎเดียวกันหรือไม่?
• ตรรกะเป็นการจัดรูปแบบข้อมูลมากกว่าการตัดสินใจเชิงธุรกิจหรือไม่?

ระบุกำกัดข้อจำกัดตั้งแต่ต้น บางอุตสาหกรรมต้องการการควบคุมการเข้าถึงเข้มงวด การแยกหน้าที่ หรือบันทึกรายละเอียด นอกจากนี้พิจารณาขอบเขตการเข้าถึงข้อมูล: ถ้ามีบริการบางตัวเท่านั้นที่ควรเห็นฟิลด์บางอย่าง นั่นก็มีผลต่อที่ที่ตรรกะสามารถรันได้อย่างปลอดภัย

เมื่อไหร่ที่ตรรกะควรอยู่ใน stored procedures

Stored procedures คือชิ้นตรรกะที่รันภายในฐานข้อมูล ใน PostgreSQL มักเขียนด้วย SQL (และบางครั้งด้วยภาษาในฐานข้อมูลอย่าง PL/pgSQL) แทนที่จะให้แอปดึงแถวออกมาลูปและเขียนกลับ ฐานข้อมูลจะทำงานตรงที่ข้อมูลอยู่

กฎง่าย ๆ คือ: ใส่ตรรกะในฐานข้อมูลเมื่อหน้าที่หลักคือปกป้องข้อมูลและทำงานกับข้อมูลจำนวนมาก ไม่ใช่การประสานงานผู้คนหรือระบบ

จุดแข็งของ stored procedures

Stored procedures เหมาะกับกฎที่ต้องเป็นจริงเสมอ ไม่ว่าแอปหรือการผสานใดจะเข้าถึงฐานข้อมูล คิดถึงราวกันตกที่ป้องกันข้อมูลเสีย

พวกมันยังเด่นในการอัพเดตแบบ set-based ที่คำสั่งเดียวสามารถอัพเดตแถวได้เป็นพัน ๆ อย่างปลอดภัยและรวดเร็ว การคำนวณง่าย ๆ ที่เกี่ยวกับข้อมูลเพียว ๆ เช่น การคำนวณยอดรวมหรือการใช้สูตรส่วนลดคงที่ ก็สามารถอยู่ที่นี่เมื่อช่วยลดรอบการเรียกและรักษาผลลัพธ์ให้สอดคล้อง

ตัวอย่าง: เมื่อคำสั่งซื้อถูกทำเครื่องหมายว่า paid stored procedure สามารถอัพเดตสถานะคำสั่งซื้อ ลดสต็อก และเขียนแถว audit ได้เป็นอะตอม หากขั้นตอนไหนล้ม ทั้งการเปลี่ยนแปลงจะย้อนกลับ

เมื่อ stored procedures เป็นความเสี่ยง

Stored procedures อาจทดสอบและเวอร์ชันได้ยากกว่าโค้ดในแอป โดยเฉพาะหากทีมไม่ปฏิบัติต่อการเปลี่ยนแปลงฐานข้อมูลเหมือนการปล่อยซอฟต์แวร์จริง ตรรกะอาจกลายเป็น “ซ่อนอยู่” จากแอป สร้างการผูกกันที่คุณค้นพบภายหลัง

การดีบักก็ยากขึ้น ข้อผิดพลาดอาจปรากฏเป็นข้อความฐานข้อมูลที่มีบริบทน้อยกว่าเกี่ยวกับสิ่งที่ผู้ใช้ทำ สมาชิกใหม่อาจสับสนเพราะกฎกระจายอยู่ทั้งแอปและฐานข้อมูล และตรรกะในฐานข้อมูลง่ายต่อการพลาดในขั้นตอนการเริ่มงาน

หากคุณใช้เครื่องมือแบบมองเห็นสำหรับตรรกะส่วนใหญ่ ให้สงวน stored procedures ไว้สำหรับคอร์เล็ก ๆ ที่มั่นคงซึ่งต้องรันใกล้ข้อมูล เก็บส่วนที่เหลือไว้ในที่ที่อ่าน ติดตาม และเปลี่ยนได้ง่ายกว่า

เมื่อตรรกะเข้ากันได้ดีกับเวิร์กโฟลว์แบบมองเห็น

เวิร์กโฟลว์แบบมองเห็นคือตรรกะกระบวนการทีละขั้นตอนที่อ่านเหมือนเช็คลิสต์: เมื่อมีบางอย่างเกิดขึ้น ให้รันการกระทำเหล่านี้ตามลำดับ พร้อมจุดตัดสินใจที่ชัดเจน มันไม่ใช่การคำนวณหนักเท่าไหร่ แต่เป็นการเคลื่อนงานผ่านคน ระบบ และเวลา

มันเด่นเมื่อคุณใส่ใจความเข้าใจร่วมกัน หากฝ่ายผลิต ภารกิจ ฝ่ายสนับสนุน และวิศวกรรมต้องตกลงกันว่าอย่างไร เวิร์กโฟลว์แบบมองเห็นทำให้กฎมองเห็นได้ ความมองเห็นนี้มักเป็นความแตกต่างระหว่าง “ระบบพัง” กับ “กระบวนการเปลี่ยนไปเมื่อสัปดาห์ที่แล้ว”

เวิร์กโฟลว์มักเหมาะกับการอนุมัติและการทบทวน การส่งต่อ การแจ้งเตือนและเตือนความจำ ขั้นตอนเวลารอ (รอ 2 วัน แล้วไล่ต่อ) และการรวม (เรียก Stripe, ส่งข้อความ, อัพเดต CRM)

ตัวอย่าง: ลูกค้าขอคืนเงิน เวิร์กโฟลว์ตรวจอายุคำสั่งซื้อ ส่งไปยังผู้จัดการหากเกินเกณฑ์ แจ้งฝ่ายการเงินเมื่ออนุมัติ และส่งอัปเดตถึงลูกค้า แต่ละขั้นชี้ชัดและง่ายต่อการอภิปรายเป็นภาษาธรรมดา ซึ่งช่วยให้ผู้มีส่วนได้ส่วนเสียลงชื่อรับรองและช่วยให้สมาชิกทีมใหม่เข้าใจ “ทำไม”

เครื่องมืออย่าง Business Process Editor ของ AppMaster ถูกสร้างมาสำหรับตรรกะประเภทนี้: คุณเห็นเส้นทาง เงื่อนไข และผลข้างเคียง (ข้อความ เรียก API การเปลี่ยนสถานะ) โดยไม่ต้องขุดสคริปต์ฐานข้อมูล

เพื่อไม่ให้เวิร์กโฟลว์กลายเป็นเส้นเลือดพันกัน ให้เก็บให้สั้นและอ่านง่าย ให้แต่ละเวิร์กโฟลว์ผลลัพธ์เดียว ใช้ชื่้อขั้นตอนและสาขาชัดเจน จำกัดการตัดสินใจซ้อนลึก ๆ และล็อกการตัดสินใจสำคัญเพื่อให้ตอบได้ว่า “ทำไมถึงเกิดเรื่องนี้” ภายหลัง

เมื่อเวิร์กโฟลว์เริ่มทำการคำนวณข้อมูลซับซ้อนหรือแตะหลายตาราง นั่นมักเป็นสัญญาณให้ย้ายส่วนของตรรกะไปที่อื่น เวิร์กโฟลว์ทำหน้าที่เป็นผู้กำกับทิศทาง ไม่ใช่ออร์เคสตราทั้งวง

เมื่อไหร่ที่โค้ดที่กำหนดเองเป็นเครื่องมือที่เหมาะสม

โค้ดที่กำหนดเองคือตรรกะที่คุณเขียนและดูแลเป็นซอฟต์แวร์: ฟังก์ชัน เซอร์วิส หรือไลบรารีขนาดเล็กที่รันเป็นส่วนหนึ่งของแอป มันเป็นตัวเลือกที่ยืดหยุ่นที่สุด และนั่นคือเหตุผลที่ควรใช้เมื่อมีเหตุผล

โค้ดสมควรได้รับที่ว่างเมื่อตรรกะยากจะอธิบายอย่างปลอดภัยใน stored procedure หรือเครื่องมือลากวาง หากคุณพบว่ากำลังบิดเครื่องมือให้เข้ากับปัญหา โค้ดมักจะชัดเจนกว่าและรักษาความถูกต้องได้ง่ายกว่า

สัญญาณชัดว่าควรใช้โค้ด:

• ปัญหาเป็นแบบอัลกอริธึม (กฎการตั้งราคา, การวางเส้นทาง, การให้คะแนน, การจับคู่, การตรวจจับการทุจริต) และมีกรณีขอบจำนวนมาก
• คุณต้องการการรวมที่ผิดปกติ (API พาร์ทเนอร์ที่มีการยืนยันตัวตนแปลก ๆ, รีไทรซับซ้อน, กฎ idempotency เฉพาะ)
• ความไวต่อประสิทธิภาพสูง (การประมวลผลปริมาณมาก, การคำนวณหนัก, การแคชที่ระมัดระวัง) และคุณต้องการการควบคุมอย่างเข้มงวด
• คุณต้องแชร์ตรรกะเดียวกันในหลายที่ (เว็บ โมบาย งานแบตช์) โดยไม่คัดลอกมัน
• คุณต้องการการทดสอบอัตโนมัติที่เข้มงวดรอบตรรกะเพราะความผิดพลาดมีราคาแพง

โค้ดยังทำให้ความเป็นเจ้าของชัดเจน ทีมสามารถรับผิดชอบการรีวิว การรักษาทดสอบให้ผ่าน และการจัดทำเอกสารพฤติกรรม นี่ดีกว่า “มันอยู่ในสามเวิร์กโฟลว์และไม่มีใครแน่ใจว่าอันไหนรันก่อน”

ตัวอย่าง: เครื่องตัดสินใจคืนเงินที่พิจารณาประวัติคำสั่งซื้อ สัญญาณการทุจริต สถานะการจัดส่ง และหน้าต่างเวลา คุณยังคงเก็บขั้นตอนการอนุมัติในเวิร์กโฟลว์ได้ แต่การตัดสินใจเองมักดีกว่าเป็นโค้ดที่มี unit tests และ version control

ต้นทุนมีจริง โค้ดที่กำหนดเองต้องการเวลา วิศวกรรม การรีวิว และการดูแลต่อเนื่อง การเปลี่ยนแปลงอาจใช้เวลานานกว่าการแก้เวิร์กโฟลว์ และต้องมีกระบวนการปล่อย AppMaster ช่วยลดปริมาณโค้ดที่ต้องเขียนโดยครอบคลุมส่วนทั่วไปด้วยตรรกะแบบมองเห็นและโมดูล ขณะเดียวกันก็ปล่อยให้ทีมส่งออกซอร์สโค้ดและขยายเมื่อจำเป็นจริง ๆ

กรอบทำงานทีละขั้นตอนที่ใช้ซ้ำได้

ทีมมักข้ามส่วนที่มีประโยชน์ที่สุด: เขียนกฎให้ชัดแล้วเลือกที่อยู่ที่สอดคล้องกับลักษณะของกฎ

ใช้กรอบนี้เมื่อมีตรรกะใหม่เกิดขึ้น:

• เขียนกฎเป็นประโยคเดียว แล้วติดป้าย หากเกี่ยวกับข้อมูลที่ถูกต้อง (ข้อจำกัด ความเป็นเอกลักษณ์ ยอดรวมที่ต้องตรงกัน) เป็นกฎข้อมูล หากเกี่ยวกับขั้นตอนและการส่งต่อ (การอนุมัติ รอ การแจ้งเตือน) เป็นกฎกระบวนการ หากเป็นคณิตศาสตร์หนักหรือการแปลงซับซ้อน เป็นกฎการคำนวณ
• ถามว่าใครแก้ไขและบ่อยแค่ไหน ถ้าคนที่ไม่ใช่เทคนิคต้องเปลี่ยนสัปดาห์ละครั้ง อย่าซ่อนมันใน SQL หรือการปล่อยโค้ด ถ้าระหว่างการเปลี่ยนแปลงน้อยและต้องบังคับทุกครั้ง ฐานข้อมูลน่าจะเหมาะกว่า
• ตรวจสอบผลกระทบเมื่อผิดพลาดและร่องรอยการตรวจสอบที่ต้องการ ถาความผิดพลาดอาจทำให้เสียเงินหรือปัญหาการปฏิบัติตาม ให้เลือกที่ที่มีการล็อกชัดเจนและการควบคุมเข้มงวด
• เลือกตำแหน่งและกำหนดขอบเขต ระบุชัดว่าป้อนเข้าอะไร ผลลัพธ์คืออะไร และข้อผิดพลาดอย่างไร ตัวอย่าง: “ให้ order_id คืน allowed_refund_amount หรือรหัสเหตุผลที่ชัดเจน” ขอบเขตนี้ช่วยป้องกันตรรกะรั่วไหลไปทั่ว
• เลือกชั้นเดียวให้บางลง ตัดสินใจว่าส่วนใดควร “ทึ่บ” น้อยที่สุดเพื่อไม่ให้ซ้ำกฎ ตัวเลือกทั่วไป: ให้ฐานข้อมูลบาง (เฉพาะความสมบูรณ์ของข้อมูล), ให้เวิร์กโฟลว์บาง (เฉพาะการออร์เคสตราเท่านั้น), หรือให้โค้ดบาง (เชื่อมต่อเท่านั้น)

กฎทอง: ใส่กฎข้อมูลให้ใกล้ข้อมูลที่สุด ใส่กฎกระบวนการในเครื่องมือเวิร์กโฟลว์ และใส่กฎการคำนวณในที่ที่ทดสอบและเวอร์ชันได้ง่ายที่สุด

ถ้าคุณใช้แพลตฟอร์มอย่าง AppMaster คุณสามารถถือว่าฐานข้อมูลเป็นราวกันตก (ตาราง ความสัมพันธ์ ข้อจำกัดพื้นฐาน) และใช้ Business Process Editor แบบมองเห็นสำหรับส่วน “ใครทำอะไรต่อไป” ขณะที่สงวนโค้ดสำหรับกรณีจำกัดจริง ๆ

ความผิดพลาดทั่วไปที่ทำให้ระบบยุ่งเหยิง

ระบบยุ่งเหยิงมักไม่เกิดจากการเลือกผิดเพียงครั้งเดียว แต่เกิดเมื่อกฎกระจาย ซ่อน หรือคัดลอกจนไม่มีใครแน่ใจว่าระบบทำงานอย่างไร

การทำซ้ำเป็นปัญหาคลาสสิก: กฎเดียวกันอยู่สองที่แต่เบี่ยงเบนตามเวลา ตัวอย่าง: ฐานข้อมูลปฏิเสธการคืนเงินเกิน $500 เว้นแต่จะมีบันทึกการอนุมัติ แต่เวิร์กโฟลว์ยังส่งคำขอคืนเงินไปที่ระบบจ่ายเงินเพราะตรวจสอบขีดจำกต่างกัน ทั้งสอง “ทำงาน” จนกว่ากรณีขอบจริงเกิดขึ้น แล้วฝ่ายซัพพอร์ตจะเจอบั๊กลึกลับ

กฎที่ซ่อนอยู่ตามมา triggers, stored procedures และการแก้ไขด่วนในฐานข้อมูลอาจมองไม่เห็นสำหรับคนที่สร้าง UI หรือเวิร์กโฟลว์ หากกฎไม่ได้เอกสารไว้ใกล้กับเวิร์กโฟลว์หรือ API ที่ขึ้นกับมัน การเปลี่ยนแปลงจะกลายเป็นการเดาและการทดสอบกลายเป็นการลองผิดลองถูก

เวิร์กโฟลว์ที่อัดแน่นเป็นความยุ่งอีกแบบหนึ่ง เส้นลากวางยาว ๆ ที่มีหลายสาขากลายเป็นสิ่งเปราะบางที่ไม่มีใครอยากแตะ ในเครื่องมืออย่าง AppMaster มันง่ายที่จะเพิ่มบล็อกเพราะเร็ว แต่ความเร็ววันนี้อาจกลายเป็นความสับสนถ้าเวิร์กโฟลว์ไม่มีขอบเขตชัดเจน

สองความผิดพลาดตรงข้ามที่ทำให้เจ็บปวดระยะยาว:

• เยอะเกินไปในฐานข้อมูล: ทุกการเปลี่ยนนโยบายกลายเป็นโครงการมิเกรชัน และการปรับแต่งผลิตภัณฑ์เล็ก ๆ ต้องรอการปล่อยฐานข้อมูล
• เยอะเกินไปในโค้ดแอป: กฎข้อมูลพื้นฐาน (ฟิลด์ที่ต้องมี สถานะที่อนุญาต ข้อจำกัดเอกลักษณ์) ถูกลืม และข้อมูลเสียซึมเข้ามาทางการนำเข้า เครื่องมือแอดมิน หรือการรวมในอนาคต

นิสัยง่าย ๆ ป้องกันสิ่งนี้ได้ส่วนใหญ่: เก็บแต่ละกฎไว้ในที่ตั้งหลักเดียว และจดบันทึกว่ามันอยู่ที่ไหนและเพราะเหตุใด ถ้าคุณตอบไม่ได้ว่า “ที่ไหนบังคับสิ่งนี้?” ใน 10 วินาที คุณก็จ่ายภาษาความยุ่งแล้ว

ตรวจสอบด่วน: ตัดสินใน 2 นาที

คุณกำลังเลือกที่ที่รักษากฎให้ถูกต้อง มองเห็นได้ และแก้ไขง่าย

เริ่มด้วยคำถามเดียว: กฎนี้เกี่ยวกับความถูกต้องของข้อมูล หมายความว่าต้องไม่มีทางข้ามมันได้หรือไม่? ถ้าใช่ วางมันให้ใกล้ฐานข้อมูล ถ้าเป็นเรื่องขั้นตอน การอนุมัติ หรือการแจ้ง ให้เก็บไว้ใกล้ชั้นเวิร์กโฟลว์

เช็คลิสต์ด่วน:

• บังคับความถูกต้องของข้อมูลหรือไม่ (ป้องกันสินค้าคงคลังติดลบ ปิดกั้นระเบียน “active” ซ้ำ)? โน้มไปฐานข้อมูล
• แตะหลายตารางและต้องอัพเดตแบบ set-based ไหม? โน้มไปฐานข้อมูล
• ต้องการร่องรอยที่อ่านโดยมนุษย์ว่าใครอนุมัติอะไรเมื่อไรไหม? โน้มไปเวิร์กโฟลว์
• ผู้ไม่ใช่วิศวกรต้องเปลี่ยนสัปดาห์หรือเดือนละครั้งไหม? โน้มไปเวิร์กโฟลว์
• เรียกบริการภายนอก (การชำระเงิน ข้อความ AI) ไหม? โน้มไปแอปหรือเวิร์กโฟลว์ ไม่ใช่ฐานข้อมูล

คิดถึงความล้มเหลวด้วย กฎที่ล้มได้ควรล้มในทางที่มนุษย์กู้คืนได้ หากต้องรีไทรอย่างปลอดภัยและข้อความข้อผิดพลาดชัดเจน เลือกชั้นออร์เคสทราเทชันที่สามารถติดตามสเตตัสและจัดการข้อยกเว้นทีละขั้นได้ เครื่องมือเวิร์กโฟลว์แบบมองเห็นมักทำให้ง่ายเพราะแต่ละขั้นชัดเจนและล็อกได้

ตัวตัดสินแบบปฏิบัติ:

• ถ้าระบบต้องถูกต้องแม้เมื่อมีคนเขียนแอปใหม่ในอนาคต ให้บังคับที่ฐานข้อมูล
• ถ้ากระบวนการถูกออกแบบให้คนปฏิบัติหรือทีมปฏิบัติการอ่านและทบทวน ให้เก็บในเวิร์กโฟลว์แบบมองเห็น
• ถ้ามีการรวมซับซ้อน การคำนวณหนัก หรือไลบรารีพิเศษ ให้ใช้โค้ด

ตัวอย่าง: “จำนวนเงินคืนไม่เกินการชำระเงินเดิม” เป็นความถูกต้อง ดังนั้นบังคับใกล้ข้อมูล “การคืนเงินเกิน $500 ต้องการการอนุมัติจากผู้จัดการแล้วส่งข้อความ Telegram” เป็นเวิร์กโฟลว์ ใน AppMaster โซ่การอนุมัตินั้นเหมาะใน Business Process Editor ในขณะที่ข้อจำกัดที่เคร่งครัดอยู่ในโมเดลข้อมูล

ตัวอย่างสถานการณ์: การคืนเงินที่ต้องอนุมัติ

กรณีจริงที่พบบ่อยคือการคืนเงินที่ต้องการการอนุมัติเมื่อเกินจำนวนหนึ่ง พร้อมการแจ้งเตือนและร่องรอยการตรวจสอบที่ชัดเจน

เริ่มจากกำหนดแหล่งความจริงเดียว: ระเบียน Refund เดียวที่มีจำนวนเงินและฟิลด์สถานะชัดเจน (เช่น: requested, needs_approval, approved, rejected, processing, paid, failed) ทุกส่วนของระบบควรอ่านและเขียนฟิลด์เดียวกัน แทนการเก็บสถานะคู่ขนานในหลายที่

อะไรควรอยู่ในฐานข้อมูล

วางกฎที่ปกป้องเงินและความสมบูรณ์ของข้อมูลให้ใกล้ข้อมูลที่สุด

ใช้ constraints (และบางครั้ง stored procedure) เพื่อให้แน่ใจว่าไม่สามารถคืนเงินเกินจำนวนที่ถูก capture, ไม่สามารถคืนคำสั่งซื้อที่คืนทั้งหมดแล้ว, ไม่สามารถสร้างคำขอคืนเงินที่ active สองรายการสำหรับคำสั่งเดียวกัน, หรือเปลี่ยนจำนวนสำคัญหลังจากอนุมัติแล้ว

ยังเก็บการอัพเดตแบบอะตอมที่นี่: เมื่อตั้งคำขอคืนเงิน ให้เขียนแถว Refund และอัพเดตยอดรวมของ Order ในทรานแซกชันเดียว หากการเขียนใดล้ม ทั้งหมดย่อมไม่ควรอัพเดตบางส่วน

อะไรเหมาะกับเวิร์กโฟลว์แบบมองเห็น

ขั้นตอนการอนุมัติเป็นเรื่องกระบวนการ ไม่ใช่การปกป้องข้อมูล เวิร์กโฟลว์แบบมองเห็นเป็นที่ที่ดีสำหรับการส่งคำขอไปยังผู้จัดการที่เหมาะสม รอการตัดสินใจ อัพเดตสถานะ ส่งเตือน และแจ้งผู้ขอ

โฟลว์ง่าย ๆ อาจเป็น: สร้างคำขอ -> ถ้าจำนวนเกินขีด ให้ตั้งสถานะเป็น needs_approval -> แจ้งผู้จัดการ -> ถ้าอนุมัติ ให้ตั้งเป็น approved -> แจ้งผู้ขอ -> ถ้าไม่มีการตอบภายใน 24 ชั่วโมง ส่งเตือน

ในเครื่องมือเช่น AppMaster สิ่งนี้แมปได้ชัดเจนเป็น Business Process ที่ตอบสนองการเปลี่ยนสถานะและทริกเกอร์อีเมล, SMS, หรือข้อความ Telegram

อะไรควรเป็นโค้ดที่กำหนดเอง

ผู้ให้บริการชำระเงินมีกรณีขอบที่ไม่ลงตัวกับกฎหรือลากวาง โค้ดควรจัดการเช่น partial refunds ที่มีค่าธรรมเนียม หรือ multi-capture, การรวม webhook (ผู้ให้บริการบอกว่า “paid” แต่แอปของคุณพูดว่า “processing”), และการจัดการ idempotency และรีไทรเมื่อผู้ให้บริการ time out

สำคัญคือโค้ดไม่ควรคิดสถานะของตัวเอง มันอ่านระเบียน Refund ทำรายการกับผู้ให้บริการ แล้วเขียนสถานะถัดไปและจำนวนที่ยืนยันกลับมาเพื่อให้ฐานข้อมูลยังคงเป็นสมุดบัญชีที่ทุกคนเชื่อถือ

ก้าวต่อไป: ทำให้การเลือกคงอยู่ได้

การตัดสินใจดีมีประโยชน์ก็ต่อเมื่อมันยังคงเป็นจริงอีกหกเดือนต่อมา เป้าหมายคือทำให้การเลือก “ตรรกะนี้ควรอยู่ที่ไหน?” ดูง่าย ทดสอบได้ และยากที่จะหลุดรอด

สร้างแผนที่ตรรกะง่าย ๆ: รายการสั้น ๆ ของกฎสำคัญและที่ที่คุณเลือกให้แต่ละกฎอยู่ เก็บให้กระชับและอัปเดตเมื่อกฎเปลี่ยน รวมชื่อกฎ ที่อยู่ที่เลือก สาเหตุหนึ่งประโยค สิ่งที่อ่านและเขียน และผู้อนุมัติการเปลี่ยนแปลง

เขียนขอบเขตเป็นสิ่งที่ไม่เจรจาเพื่อปกป้องระบบเมื่อมีคนเพิ่มฟีเจอร์ในอนาคต รูปแบบที่เป็นประโยชน์เช่น: “ฐานข้อมูลรับประกัน X” และ “เวิร์กโฟลว์บังคับ Y” เช่น ฐานข้อมูลรับประกันว่าไม่สามารถมีระเบียน refund โดยไม่มี order ในขณะที่เวิร์กโฟลว์บังคับว่าการคืนเงินเกิน $500 ต้องได้รับการอนุมัติจากผู้จัดการ

วางแผนการทดสอบก่อนเปลี่ยนอะไร คุณไม่จำเป็นต้องมีแผนทดสอบใหญ่ แค่ไม่กี่เคสที่คุณจะรันซ้ำทุกครั้งที่กฎเปลี่ยน:

• Happy path (อินพุตปกติ ผลลัพธ์ที่คาดไว้)
• Failure path (ข้อมูลขาดหาย สถานะไม่ถูกต้อง คำขอซ้ำ)
• Concurrency (สองคนกระทำการเดียวกันพร้อมกัน)
• Security (ผู้ใช้พยายามข้ามขั้นตอนหรือเรียก endpoint โดยตรง)

ตั้งความเป็นเจ้าของและกฎการรีวิวด้วย ตัดสินว่าใครแก้ stored procedures ใครแก้เวิร์กโฟลว์ และอะไรต้อง peer review นั่นคือจุดที่หลายระบบยังคงแข็งแรงหรือถลำสู่สภาพ “ไม่มีใครรู้ว่าทำไมมันใช้งานได้”

ถ้าคุณต้องการเวิร์กโฟลว์แบบลากวางโดยไม่เสียโครงสร้างแบ็กเอนด์จริง AppMaster (appmaster.io) เป็นจุดกึ่งกลางที่ใช้งานได้: โมเดลข้อมูลของคุณ แสดงกระบวนการใน Business Process Editor แล้วสร้างและปรับใช้เมื่อความต้องการเปลี่ยน

เลือกกฎหนึ่งข้อที่มีผลสูง แม็ปมัน กำหนดขอบเขต และเขียนสามเคสทดสอบ นิสัยเดียวนี้ป้องกันการแพร่ขยายตรรกะส่วนใหญ่ได้