สถาปัตยกรรมแบบเติบโตตามธรรมชาติ: ปรัชญา Write First, Organize Later

ในวงการพัฒนาซอฟต์แวร์ เรามักจะถูกพร่ำสอนมาตลอดว่า “ต้องคิดทุกอย่างให้จบก่อนเริ่มเขียนโค้ด”

เราใช้เวลาหลายสัปดาห์ในห้องประชุมเพื่อวาด UML Diagram ให้สมบูรณ์แบบ เราพยายามออกแบบ Database Schema ให้ครอบคลุมฟีเจอร์ในอนาคตไปอีก 3–5 ปี เราสร้างตาราง สร้างความสัมพันธ์ (Relations) ที่ซับซ้อนราวกับใยแมงมุม เพื่อหวังว่ามันจะรองรับทุกความต้องการของธุรกิจได้

Photo by Orgalux on Unsplash

แต่ในโลกความเป็นจริง… ยิ่งเราพยายามสร้างโครงสร้างที่ “สมบูรณ์แบบ” ตั้งแต่วันแรกมากเท่าไหร่ ระบบของเราก็ยิ่งเปราะบาง (Fragile) และกลายเป็นกรงขังทีมพัฒนาเสียเองเมื่อ Requirement เปลี่ยนทิศทาง

วันนี้เราจะมาก้าวออกจากกรอบคิดแบบ Big Design Up Front แล้วลองมองการออกแบบระบบผ่านเลนส์ของการจัดการความรู้ (Knowledge Management) และปรัชญาสโตอิกครับ

กับดักของการจัดระเบียบ (The Organization Trap)

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

เรามักจะเริ่มจากการ “สร้างโฟลเดอร์” เราจัดหมวดหมู่ สร้าง Template ที่สวยงาม แบ่งเป็นโฟลเดอร์งาน โฟลเดอร์ส่วนตัว โฟลเดอร์ไอเดีย… เราใช้พลังงานมหาศาลไปกับการสร้างโครงสร้าง (Organize) ก่อนที่จะมีเนื้อหา (Content) เสียอีก และเมื่อไหร่ก็ตามที่เรามีไอเดียใหม่ที่ดันไม่เข้าพวกกับโครงสร้างที่เตรียมไว้ สมองเราจะชะงักทันที

ในโลกของการจัดการความรู้ส่วนบุคคล โดยเฉพาะกลุ่มคนที่หลงใหลในเครื่องมือสาย Utility-first อย่าง Obsidian จะมีปรัชญาหลักข้อหนึ่งที่ทรงพลังมาก นั่นคือ “Write First, Organize Later” (จดไปก่อน ค่อยจัดระเบียบทีหลัง)

แทนที่จะเริ่มต้นด้วยโครงสร้างที่แข็งทื่อ เราเริ่มต้นจากการบันทึก “ความจริง” หรือไอเดียดิบ ๆ ลงไปก่อน ปล่อยให้มันไหลไปตามธรรมชาติ แล้วใช้การเชื่อมโยง (Link) เข้าหากันในภายหลัง โครงสร้างของความรู้จะไม่ได้เกิดจากการคาดเดาล่วงหน้า แต่มันจะ “งอกเงย (Emerge)” ขึ้นมาจากพฤติกรรมการใช้งานจริงของเรา (Self-Organization)

Event Sourcing: เมื่อซอฟต์แวร์จำลองพฤติกรรมมนุษย์

หากเรานำปรัชญา Write First, Organize Later มาทาบทาบลงบนโลกของ System Architecture เราจะได้พบกับแนวคิดที่เรียกว่า Event Sourcing และ CQRS (Command Query Responsibility Segregation)

ในสถาปัตยกรรมฐานข้อมูลแบบดั้งเดิม (CRUD) สมมติว่าเราทำแพลตฟอร์ม Sharing Grocery เมื่อผู้ใช้งานหยิบกะหล่ำปลีใส่ตะกร้า 1 หัว เราบันทึก item_count = 1 เมื่อเขาเปลี่ยนใจเพิ่มเป็น 2 หัว เราก็เข้าไปแก้ (Update) ข้อมูลเดิมทับเป็น item_count = 2

วิธีนี้คือการพยายามจัดระเบียบข้อมูลให้เป็น “สถานะปัจจุบัน (Current State)” ตลอดเวลา ข้อเสียคือเราสูญเสียร่องรอยของอดีตไปอย่างถาวร

แต่ Event Sourcing ทำงานต่างออกไป มันคือแอปจดโน้ตแบบ Write First เราจะไม่เซฟสถานะสุดท้ายทับลงไป แต่เราจะเซฟ “เหตุการณ์ดิบที่เกิดขึ้น (Raw Events)” เรียงต่อกันไปเรื่อย ๆ อย่างเป็นลำดับเวลา:

• Event 1: User สร้างตะกร้า
• Event 2: User เพิ่มกะหล่ำปลี 1 หัว
• Event 3: User เพิ่มกะหล่ำปลีอีก 1 หัว
• Event 4: User ลบกะหล่ำปลีออก 1 หัว

เราบันทึกเพียง “ความจริงระดับเล็กที่สุดที่เปลี่ยนแปลงไม่ได้ (Immutable Facts)” นี่คือขั้นตอนของ Write First

ทีนี้มาถึงท่อน Organize Later (ซึ่งก็คือส่วนของ CQRS) สมมติว่าวันดีคืนดี ทีม Data พุ่งเข้ามาบอกว่า “เราอยากรู้พฤติกรรมว่า ลูกค้ามักจะลบสินค้าตัวไหนออกจากตะกร้ามากที่สุดก่อนกดจ่ายเงิน”

ถ้าระบบเราเป็นแบบ CRUD ดั้งเดิม เราจบเห่ครับ เพราะข้อมูลตอนที่ลูกค้าลบสินค้ามันถูกเซฟทับหายไปแล้ว แต่ด้วย Event Sourcing เรามี Raw Events ทั้งหมดเก็บไว้ เราสามารถนำความจริงเหล่านี้มา “จัดระเบียบใหม่” สร้างเป็น Read Model หรือ Projection หน้าตาใหม่เพื่อตอบโจทย์ Business Requirement ในวันนี้ได้ทันที โดยไม่ต้องไปรื้อโครงสร้างฐานข้อมูลเดิมเลย

สถาปัตยกรรมแบบสโตอิก (Stoic Architecture)

หากมองในมุมของลัทธิ สโตอิก (Stoicism) อีพิคเตตัส (Epictetus) เคยกล่าวไว้ว่า ความทุกข์ของมนุษย์เกิดจากการพยายามควบคุมในสิ่งที่เราควบคุมไม่ได้

การพยายามออกแบบ Database Schema ให้เพอร์เฟกต์รองรับอนาคตไปอีก 5 ปี ก็คือการพยายาม “ควบคุมอนาคต” ซึ่งเป็นสิ่งที่เป็นไปไม่ได้ครับ ยิ่งเราพยายามตีกรอบล่วงหน้า ระบบเราก็ยิ่งพังทลายง่ายเมื่อเจอกับความเปลี่ยนแปลง

สถาปัตยกรรมที่ยั่งยืน ต้องเป็นสถาปัตยกรรมที่ยอมรับในความไม่รู้ (Embrace Ignorance)

เราต้องยอมรับว่า “ณ วันนี้ ฉันรู้แค่นี้ ฉันจึงบันทึกแค่ความจริงที่เกิดขึ้นตรงหน้า (Write First)” และปล่อยพื้นที่ว่างแห่งความเป็นไปได้ ทิ้งไว้ให้ตัวเรา (หรือทีมของเรา) ในอนาคต เป็นผู้นำความจริงเหล่านั้นไปตีความและจัดระเบียบ (Organize Later) เมื่อเวลาที่เหมาะสมมาถึง

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

ฟังเนื้อหาฉบับเต็มและถกประเด็นนี้แบบเจาะลึกได้ใน: Uncle Quin Podcast EP.36 | สถาปัตยกรรมแบบเติบโตตามธรรมชาติ

หากคุณชอบบทความแนวการเชื่อมโยงปรัชญาเข้ากับการทำงานในโลกยุคใหม่ ฝากกดเลิฟ กดแชร์ และกดติดตามช่องของผมด้วยนะครับ!

• Spotify
• YouTube