29 ต.ค. 2568·3 นาที
โค้ดเบสเดียวที่สร้างโดย AI สำหรับเว็บ มือถือ และ API
ดูว่าการมีโค้ดเบสเดียวที่สร้างโดย AI จะขับเคลื่อนเว็บ แอปมือถือ และ API ได้อย่างไร ด้วยตรรกะร่วม แบบจำลองข้อมูลที่สอดคล้อง และการปล่อยใช้งานที่ปลอดภัยขึ้น
ดูว่าการมีโค้ดเบสเดียวที่สร้างโดย AI จะขับเคลื่อนเว็บ แอปมือถือ และ API ได้อย่างไร ด้วยตรรกะร่วม แบบจำลองข้อมูลที่สอดคล้อง และการปล่อยใช้งานที่ปลอดภัยขึ้น
"โค้ดเบสเดียว" มักจะไม่ได้หมายถึง UI เดียวที่รันได้ทุกที่ ในทางปฏิบัติ มันมักหมายถึง รีโพสิตอรีเดียวและชุดกฎร่วม—โดยมีพื้นผิวการส่งมอบแยกกัน (เว็บแอป แอปมือถือ API) ที่ทั้งหมดขึ้นกับการตัดสินใจธุรกิจพื้นฐานเดียวกัน
โมเดลง่าย ๆ ที่ใช้ได้คือการแชร์ส่วนที่ไม่ควรขัดแย้งกัน:
ขณะเดียวกัน โดยปกติคุณ จะไม่ แชร์เลเยอร์ UI ทั้งหมด เว็บและมือถือมีรูปแบบการนำทาง ความคาดหวังด้านการเข้าถึง ประสิทธิภาพ และความสามารถของแพลตฟอร์มที่ต่างกัน การแชร์ UI อาจเป็นประโยชน์ในบางกรณี แต่ไม่ใช่คำนิยามของ "โค้ดเบสเดียว"
โค้ดที่สร้างโดย AI สามารถเร่งได้มากในการ:\n
แต่ AI จะไม่สร้างสถาปัตยกรรมที่สอดคล้องโดยอัตโนมัติ หากไม่มีขอบเขตที่ชัดเจน มันมักจะทำให้ตรรกะซ้ำซ้อนข้ามแอป ผสมหน้าที่ (UI เรียกใช้โค้ดฐานข้อมูลโดยตรง) และสร้างการตรวจสอบความถูกต้องที่ "เกือบจะเหมือนกัน" ในหลายที่ ผลประโยชน์เกิดจากการกำหนดโครงสร้างก่อน—แล้วใช้ AI เติมส่วนที่ซ้ำซาก
โค้ดเบสเดียวที่มี AI ช่วยถือว่าเป็นความสำเร็จเมื่อมันส่งมอบ:
โค้ดเบสเดียวทำงานได้เมื่อคุณชัดเจนว่าเป้าหมายคืออะไร—และสิ่งที่มัน ไม่ควร พยายามทำให้เหมือนกัน เว็บ มือถือ และ API ให้บริการผู้ใช้และรูปแบบการใช้งานต่างกัน แม้จะแชร์กฎธุรกิจเดียวกัน
ผลิตภัณฑ์ส่วนใหญ่มี “ประตูหน้า” อย่างน้อยสามแบบ:
เป้าหมายคือความสอดคล้องใน พฤติกรรม (กฎ, สิทธิ์, การคำนวณ)—ไม่ใช่ประสบการณ์ที่เหมือนกันเป๊ะ
รูปแบบความล้มเหลวยอดนิยมคือการปฏิบัติต่อ "โค้ดเบสเดียว" เป็น "UI เดียว" นั่นมักทำให้เว็บดูเหมือนไมโครมือถือหรือมือถือดูเป็นเว็บ—ทั้งสองอย่างน่าหงุดหงิด
ให้มุ่งหวัง:
โหมดออฟไลน์: มือถือมักต้องการการอ่าน (และบางครั้งการเขียน) โดยไม่มีเครือข่าย นั่นหมายถึงการจัดเก็บในเครื่อง ยุทธศาสตร์ซิงค์ การจัดการความขัดแย้ง และกฎ "แหล่งความจริง" ที่ชัดเจน
ประสิทธิภาพ: เว็บสนใจขนาดบันเดิลและเวลาในการโต้ตอบ; มือถือสนใจเวลาเริ่มต้นและประสิทธิภาพเครือข่าย; API สนใจความหน่วงและอัตราผ่านข้อมูล การแชร์โค้ดไม่ควรหมายถึงการส่งโมดูลที่ไม่จำเป็นไปยังลูกค้าทุกคน
ความปลอดภัยและการปฏิบัติตามกฎ: การพิสูจน์ตัวตน การอนุญาต ติดตามการตรวจสอบ การเข้ารหัส และการเก็บรักษาข้อมูลต้องสอดคล้องในทุกพื้นผิว หากคุณปฏิบัติในพื้นที่ที่มีกฎเกณฑ์ ให้ใส่ความต้องการอย่างเช่นการบันทึก ความยินยอม และการเข้าถึงแบบน้อยที่สุดตั้งแต่ต้น—ไม่ใช่เป็นการปะต่อทีหลัง
โค้ดเบสเดียวทำงานได้ดีที่สุดเมื่อจัดระเบียบเป็นเลเยอร์ที่ชัดเจนพร้อมความรับผิดชอบที่เคร่งครัด โครงสร้างนั้นยังทำให้โค้ดที่สร้างโดย AI ตรวจสอบ ทดสอบ และแทนที่ได้ง่ายโดยไม่ทำลายส่วนที่ไม่เกี่ยวข้อง
นี่คือรูปทรงพื้นฐานที่ทีมส่วนใหญ่มักยอมรับ:\n
\nClients (Web / Mobile / Partners)\n ↓\n API Layer\n ↓\n Domain Layer\n ↓\n Data Sources (DB / Cache / External APIs)\n\n
แนวคิดสำคัญ: ส่วนต่อประสานผู้ใช้และรายละเอียดการรับส่งข้อมูลยืนอยู่ที่ขอบ ขณะที่กฎธุรกิจอยู่ตรงกลาง
"คอร์ที่แชร์ได้" คือทุกอย่างที่ควรมีพฤติกรรมเดียวกันทุกที่:\n
โค้ดบางอย่างมีค่าใช้จ่าย (หรือเสี่ยง) หากพยายามบังคับให้แชร์เป็นนามธรรม:\n
เลเยอร์โดเมนที่ใช้ร่วมกันคือส่วนของโค้ดเบสที่ควรรู้สึกว่า "น่าเบื่อ" ในทางที่ดี: คาดเดาได้ ทดสอบได้ และนำกลับมาใช้ได้ทุกที่ หาก AI ช่วยสร้างระบบ ชั้นนี้คือที่ที่คุณยึดความหมายของโปรเจ็กต์—เพื่อให้หน้าจอเว็บ ฟลูว์มือถือ และ endpoint API สะท้อนกฎเดียวกัน
กำหนดแนวคิดแกนหลักของผลิตภัณฑ์เป็น entities (สิ่งที่มีตัวตนข้ามเวลา เช่น Account, Order, Subscription) และ value objects (สิ่งที่กำหนดด้วยค่า เช่น Money, EmailAddress, DateRange) แล้วจับพฤติกรรมเป็น use cases (หรือ application services): "Create order," "Cancel subscription," "Change email."
โครงสร้างนี้ทำให้โดเมนเข้าใจได้สำหรับคนทั่วไป: คำนามบอกสิ่งที่มีอยู่ คำกริยาบอกสิ่งที่ระบบทำได้
ตรรกะธุรกิจไม่ควรรู้ว่ามันถูกทริกเกอร์จากการแตะปุ่ม ส่งฟอร์มเว็บ หรือคำขอ API อย่างไร โดยปฏิบัติ หมายความว่า:\n
เมื่อ AI สร้างโค้ด การแยกส่วนนี้มักจะหายไป—โมเดลสามารถยัดข้อกังวลเกี่ยวกับ UI เข้าไปในโมเดลได้ จงมองว่าการรีแฟกเตอร์เป็นทริกเกอร์ ไม่ใช่ความชื่นชอบ
การตรวจสอบความถูกต้องคือจุดที่ผลิตภัณฑ์มักจะเบี้ยว: เว็บอนุญาตบางอย่างที่ API ปฏิเสธ หรือมือถือตรวจสอบต่างกัน ใส่ การตรวจสอบความถูกต้องที่สอดคล้อง ไว้ในเลเยอร์โดเมน (หรือโมดูลการตรวจสอบร่วม) เพื่อให้พื้นผิวทั้งหมดบังคับใช้กฎเดียวกัน
ตัวอย่าง:\n
EmailAddress ตรวจสอบรูปแบบครั้งเดียว ใช้ซ้ำทั้งเว็บ/มือถือ/API\n- Money ป้องกันยอดติดลบ ไม่ว่าค่าจะมาจากที่ใด\n- Use cases บังคับกฎข้ามฟิลด์ (เช่น "วันที่สิ้นสุดต้องหลังวันที่เริ่ม")\n
ถ้าทำได้ดี เลเยอร์ API จะกลายเป็นตัวแปล และเว็บ/มือถือเป็นผู้แสดงผล—ขณะที่โดเมนเป็นแหล่งความจริงเพียงแห่งเดียวเลเยอร์ API คือ "ใบหน้าสาธารณะ" ของระบบ—และในโค้ดเบสเดียวที่สร้างโดย AI มันควรเป็นส่วนที่ยึดทุกอย่าง หากสัญญาชัดเจน เว็บ แอป มือถือ และแม้แต่บริการภายในสามารถถูกสร้างและตรวจสอบตามแหล่งความจริงเดียวกัน
กำหนดสัญญาก่อนจะสร้างฮันเดลเลอร์หรือการเชื่อม UI:\n
/users, /orders/{id}), การกรองและการเรียงลำดับที่คาดเดาได้\n- ข้อผิดพลาด: รูปร่างข้อผิดพลาดที่เสถียร (code, message, details) พร้อมการใช้ HTTP status ที่ชัดเจน\n- การแบ่งหน้า: เลือกแนวทางเดียว (cursor-based มักง่ายต่อการพัฒนา) และมาตรฐานฟิลด์ตอบกลับ\n- การทำเวอร์ชัน: ตัดสินใจแต่เนิ่น ๆ (เช่น path /v1/... หรือ header-based) และบันทึกกฎการยกเลิกใช้ OpenAPI (หรือเครื่องมือ schema-first เช่น GraphQL SDL) เป็นเอกสารหลัก จากนั้นสร้าง:\n
นี่มีความสำคัญสำหรับโค้ดที่สร้างโดย AI: โมเดลสามารถสร้างโค้ดจำนวนมากได้เร็ว แต่สคีมาจะช่วยให้โค้ดสอดคล้องกัน
ตั้งไม่กี่ข้อที่ยอมไม่ได้:\n
snake_case หรือ camelCase ไม่ใช้ทั้งสอง; ให้ตรงกันระหว่าง JSON และประเภทที่สร้าง\n- รหัสสถานะ: 200/201/204 สำหรับความสำเร็จ, 400 สำหรับการตรวจสอบ, 401/403 สำหรับ auth, 409 สำหรับความขัดแย้ง\n- Idempotency: ขอให้มี Idempotency-Key สำหรับการดำเนินการเสี่ยง (การชำระเงิน, การสร้างคำสั่งซื้อ) และกำหนดพฤติกรรมการลองใหม่\n
ปฏิบัติกับสัญญา API เหมือนเป็นผลิตภัณฑ์ เมื่อมันเสถียร ทุกอย่างอื่นจะง่ายต่อการสร้าง ทดสอบ และปล่อยเว็บแอปได้ประโยชน์มากจากตรรกะธุรกิจที่ใช้ร่วม และได้รับผลร้ายเมื่อมันพันกันกับข้อกังวล UI กุญแจคือการปฏิบัติต่อเลเยอร์โดเมนร่วมเป็น "เครื่องยนต์แบบ headless": มันรู้กฎ การตรวจสอบ และฟลูว์ แต่ไม่รู้เรื่องคอมโพเนนต์ เส้นทาง หรือ API ของเบราว์เซอร์
หากใช้ SSR (server-side rendering) โค้ดที่แชร์ต้องปลอดภัยเมื่อนำไปรันบนเซิร์ฟเวอร์: ห้ามเรียก window, document, หรือการจัดเก็บของเบราว์เซอร์โดยตรง นั่นเป็นแรงบีบที่ดี: เก็บพฤติกรรมที่ขึ้นกับเบราว์เซอร์ไว้ในเลเยอร์อะแดปเตอร์เว็บบาง ๆ
กับ CSR (client-side rendering) คุณมีเสรีภาพมากขึ้น แต่วินัยเดียวกันยังคุ้มค่า โครงการที่เป็น CSR เท่านั้นมักจะ "เผลอ" นำเข้าโค้ด UI เข้าสู่โมดูลโดเมนเพราะทุกอย่างรันในเบราว์เซอร์—จนกว่าคุณจะเพิ่ม SSR, edge rendering, หรือตรึงการทดสอบบน Node
กฎปฏิบัติ: โมดูลที่แชร์ควรเป็นไปได้ในการทำนายและไม่ขึ้นกับสภาพแวดล้อม; สิ่งที่แตะ cookies, localStorage, หรือ URL ควรอยู่ในเลเยอร์เว็บ
ตรรกะร่วมสามารถเปิดเผย สถานะโดเมน (เช่น ยอดรวมคำสั่งซื้อ, ความเหมาะสม, ธงที่ได้คำนวณ) ผ่านออบเจกต์ธรรมดาและฟังก์ชันบริสุทธิ์ เว็บแอปควรเป็นเจ้าของ สถานะ UI: สปินเนอร์การโหลด โฟกัสของฟอร์ม แอนิเมชันแบบมองการณ์ล่วงหน้า การมองเห็นโมดอล
สิ่งนี้ทำให้การจัดการสถานะใน React/Vue ยืดหยุ่น: คุณสามารถเปลี่ยนไลบรารีโดยไม่ต้องเขียนตรรกะธุรกิจใหม่
เลเยอร์เว็บควรจัดการ:\n
localStorage, แคช)จงมองเว็บแอปเป็นอะแดปเตอร์ที่แปลงการโต้ตอบผู้ใช้เป็นคำสั่งโดเมน—และแปลผลลัพธ์โดเมนเป็นหน้าจอที่เข้าถึงได้
แอปมือถือได้ประโยชน์มากจากเลเยอร์โดเมนร่วม: กฎการตั้งราคา ความเหมาะสม การตรวจสอบความถูกต้อง และฟลูว์ควรทำงานเหมือนกับเว็บและ API UI มือถือเป็น "เปลือก" รอบตรรกะร่วมที่ปรับแต่งให้เหมาะกับการสัมผัส การเชื่อมต่อไม่ต่อเนื่อง และฟีเจอร์อุปกรณ์
แม้จะมีตรรกะธุรกิจร่วม มือถือก็มีรูปแบบที่ไม่ค่อยแมป 1:1 กับเว็บ:\n
ถ้าคาดหวังการใช้งานมือถือจริง ๆ ให้สมมติออฟไลน์:\n
โค้ดเบสเดียวแตกเมื่อเว็บ มือถือ และ API แต่ละตัวคิดรูปแบบข้อมูลและกฎความปลอดภัยต่างกัน แก้ไขโดยการถือว่ารูปแบบ โมเดลการพิสูจน์ตัวตน และการอนุญาตเป็นการตัดสินใจของผลิตภัณฑ์ที่ใช้ร่วม แล้วเข้ารหัสครั้งเดียว
เลือกที่เดียวที่โมเดลอยู่ แล้วให้ทุกอย่างอื่นสร้างจากมัน ตัวเลือกทั่วไปคือ:\n
OrderStatus มีห้าค่าในไคลเอนต์หนึ่งและหกค่าในอีกที่ AI จะคอมไพล์ได้แต่ยังส่งบั๊กการพิสูจน์ตัวตนควรให้ความรู้สึกเหมือนกันต่อผู้ใช้ แต่กลไกต่างกันตามพื้นผิว:\n
สิทธิ์ควรกำหนดครั้งเดียว—ใกล้กับกฎธุรกิจที่สุด—แล้วใช้ทั่ว:\n
canApproveInvoice(user, invoice))\n- บังคับที่ API เพื่อความปลอดภัยจริงจัง\n- สะท้อนใน UI เพื่อซ่อน/ปิดการใช้งานการกระทำ ไม่ใช่เพื่อปกป้องข้อมูลวิธีนี้ป้องกันการเบี้ยวระหว่างแพลตฟอร์มและให้การสร้างโค้ดด้วย AI มีสัญญาชัดเจนที่ทดสอบได้สำหรับว่าใครทำอะไรได้บ้าง
โค้ดเบสรวมจะยังคงรวมกันต่อเมื่อตัวบิลด์และการปล่อยเป็นไปอย่างคาดการณ์ได้ เป้าหมายคือต้องให้ทีมปล่อย API เว็บ และแอปมือถืออย่างอิสระ—โดยไม่ต้องแยกตรรกะหรือทำ "special casing" ของสภาพแวดล้อม
monorepo (รีโพเดียว หลายแพ็กเกจ/แอป) มักเหมาะกับโค้ดเบสเดียวเพราะตรรกะโดเมนร่วม สัญญา API และไคลเอนต์ UI พัฒนาไปด้วยกัน คุณได้การเปลี่ยนแปลงอะตอมิก (PR เดียวอัปเดตสัญญาและผู้บริโภคทั้งหมด) และรีแฟกเตอร์ง่ายขึ้น
multi-repo ยังรวมกันได้ แต่ต้องจ่ายด้วยการประสานงาน: เวอร์ชันแพ็กเกจร่วม การเผยแพร่ artifacts และการซิงโครไนซ์การเปลี่ยนแปลงที่ทำลาย หากขอบเขตองค์กร กฎความปลอดภัย หรือขนาดทำให้ monorepo เป็นไปไม่ได้ ให้เลือก multi-repo
ปฏิบัติกับแต่ละพื้นผิวเป็นเป้าหมายบิลด์แยกที่ใช้แพ็กเกจร่วม:\n
พายป์ไลน์ทั่วไปคือ: lint → typecheck → unit tests → contract tests → build → security scan → deploy\n แยกคอนฟิกออกจากโค้ด: ตัวแปรสภาพแวดล้อมและความลับเก็บใน CI/CD และ secret manager ไม่ใช่ในรีโพ ใช้ overlay ตามสภาพแวดล้อม (dev/stage/prod) เพื่อให้อาร์ติแฟ็กต์เดียวถูกโปรโมตข้ามสภาพแวดล้อมโดยไม่ต้องบิลด์ซ้ำ—โดยเฉพาะสำหรับ API และ runtime เว็บ
เมื่อเว็บ มือถือ และ API ปล่อยจากโค้ดเบสเดียว การทดสอบหยุดเป็นแค่ "เช็คลิสต์เพิ่มเติม" และกลายเป็นกลไกที่ป้องกันการเปลี่ยนเล็กน้อยให้พังทั้งสามผลิตภัณฑ์ เป้าหมายคือ: ตรวจจับปัญหาในที่ที่แก้ได้ถูกและบล็อกการเปลี่ยนแปลงที่เสี่ยงก่อนถึงผู้ใช้
เริ่มจากโดเมนร่วม (ตรรกะธุรกิจ) เพราะมันถูกใช้งานซ้ำมากและทดสอบได้ง่ายโดยไม่ต้องโครงสร้างพื้นฐานที่ช้า\n
แม้อยู่ใน monorepo ก็ง่ายสำหรับ API ที่เปลี่ยนในทางที่คอมไพล์ได้แต่ทำลายประสบการณ์ การทดสอบสัญญาป้องกันการเปลี่ยนแปลงเงียบ ๆ\n
การทดสอบดีมีค่า แต่กฎรอบ ๆ มันก็สำคัญเช่นกัน\n
ด้วยเกตเหล่านี้ การเปลี่ยนแปลงที่มี AI ช่วยสามารถบ่อยครั้งโดยไม่เปราะบาง
AI เร่งความเร็วโค้ดเบสเดียวได้ แต่ต้องถือมันเหมือนวิศวกรจูเนียร์ที่เร็ว: เก่งในการผลิตร่าง แต่ไม่ปลอดภัยที่จะรวมโดยไม่ตรวจ ท้ายที่สุด เป้าหมายคือใช้ AI เพื่อความเร็ว ในขณะที่มนุษย์ยังรับผิดชอบสถาปัตยกรรม สัญญา และความสอดคล้องระยะยาว
ใช้ AI เพื่อสร้าง "รุ่นแรก" ที่คุณมักจะเขียนด้วยตนเองในงานเชิงกล:\n
ผลลัพธ์ AI ควรถูกจำกัดด้วยกฎชัดเจน ไม่ใช่ความรู้สึก ตั้งกฎเหล่านี้ไว้ในที่ที่โค้ดอยู่:\n
ความเสี่ยงไม่ได้มีแค่โค้ดไม่ดี—แต่ยังรวมถึงการตัดสินใจที่ไม่ได้บันทึก เก็บรอยตรวจสอบ:\n
AI มีค่าสูงสุดเมื่อทำซ้ำได้: ทีมเห็น ทำไม มันถูกสร้าง ตรวจสอบได้ และสร้างซ้ำได้อย่างปลอดภัยเมื่อความต้องการเปลี่ยน
ถ้าคุณนำ AI มาช่วยพัฒนาระบบ (เว็บ + API + มือถือ) ฟีเจอร์ที่สำคัญที่สุดไม่ใช่ความเร็วการสร้าง แต่เป็นความสามารถในการรักษาผลลัพธ์ให้สอดคล้องกับสัญญาและเลเยอร์
ตัวอย่างเช่น Koder.ai เป็นแพลตฟอร์มที่ช่วยทีมสร้างแอปเว็บ เซิร์ฟเวอร์ และมือถือผ่านอินเทอร์เฟซแชท—ในขณะที่ยังผลิตซอร์สโค้ดจริงที่ส่งออกได้ ในทางปฏิบัติ นั่นเป็นประโยชน์สำหรับเวิร์กโฟลว์ที่อธิบายในบทความนี้: คุณสามารถกำหนดสัญญา API และกฎโดเมน แล้ววนพัฒนาอย่างรวดเร็วบนพื้นฐาน React เว็บ, Go + PostgreSQL แบ็กเอนด์, และ Flutter มือถือ โดยไม่สูญเสียความสามารถในการตรวจสอบ ทดสอบ และบังคับขอบเขตสถาปัตยกรรม คุณสมบัติเช่นโหมดการวางแผน สแนปชอต และการย้อนกลับก็สอดคล้องกับวินัยการปล่อยแบบ "generate → verify → promote" ในโค้ดเบสแบบรวม
โค้ดเบสเดียวช่วยลดการทำซ้ำ แต่ไม่ใช่ตัวเลือก "ดีที่สุด" โดยอัตโนมัติ เมื่อโค้ดที่แชร์เริ่มบังคับ UX อย่างไม่เหมาะสม ชะลอการปล่อย หรือซ่อนความแตกต่างของแพลตฟอร์ม คุณจะเสียเวลาตกลงสถาปัตยกรรมมากกว่าปล่อยคุณค่า
โค้ดเบสแยก (หรืออย่างน้อยเลเยอร์ UI แยก) มักสมเหตุสมผลเมื่อ:\n
ถามตัวเองก่อนยืนยันโค้ดเบสเดียว:\n
หากคุณต้องการความช่วยเหลือในการเลือกเส้นทาง ลองเปรียบเทียบตัวเลือกใน pricing หรือเรียกดูรูปแบบสถาปัตยกรรมที่เกี่ยวข้องใน blog.
โดยทั่วไปหมายถึง รีโพสิตอรีเดียวและชุดกฎร่วม ไม่ใช่แอปเดียวที่เหมือนกันทุกที่
ในทางปฏิบัติ เว็บ มือถือ และ API มักจะแชร์ เลเยอร์โดเมน (กฎธุรกิจ การตรวจสอบความถูกต้อง กรณีการใช้งาน) และมักมี สัญญา API เดียว ขณะที่แต่ละแพลตฟอร์มมี UI และการผสานกับแพลตฟอร์มของตัวเอง
แชร์สิ่งที่ต้องไม่ขัดแย้งกัน:
เก็บคอมโพเนนต์ UI, การนำทาง และการผสานอุปกรณ์/เบราว์เซอร์ไว้เฉพาะแพลตฟอร์ม
AI ช่วยเร่งการสร้างโครงร่างและงานซ้ำ ๆ (CRUD, ไคลเอนต์, การทดสอบ) แต่ไม่ทำให้ขอบเขตดีโดยอัตโนมัติ
หากไม่มีสถาปัตยกรรมที่ชัดเจน โค้ดที่สร้างโดย AI มักจะ:
ใช้ AI เพื่อเติมส่วนที่กำหนดไว้ดีแล้ว ไม่ใช่ให้มันคิดโครงสร้าง
โฟลว์ง่าย ๆ ที่เชื่อถือได้คือ:
แนวคิดคือ UI และรายละเอียดการส่งข้อมูลอยู่ที่ขอบ ในขณะที่กฎธุรกิจอยู่ตรงกลาง
ใส่การตรวจสอบความถูกต้องไว้ที่เดียว (โดเมนหรือโมดูลตรวจสอบร่วม) แล้วนำกลับมาใช้ทุกที่
รูปแบบปฏิบัติได้:
EmailAddress และ Money แค่ครั้งเดียววิธีนี้ป้องกันไม่ให้เกิดสถานการณ์ที่ "เว็บรับได้ แต่ API ปฏิเสธ"
ใช้สคีมาเช่น OpenAPI (หรือ GraphQL SDL) เป็นแหล่งข้อมูลหลัก แล้วสร้างจากมัน:
เพิ่มการทดสอบสัญญาเพื่อให้การเปลี่ยนแปลงที่ทำลายสคีมาล้มเหลวก่อนรวมโค้ด
ออกแบบโหมดออฟไลน์อย่างตั้งใจ แทนการหวังว่าแคชจะทำงาน:
เก็บการจัดเก็บและการซิงค์ไว้ที่เลเยอร์แอปมือถือ ส่วนกฎธุรกิจอยู่ในโดเมนร่วม
ใช้โฟลว์เชิงแนวคิดเดียว แต่ลงมือให้เหมาะกับแต่ละพื้นผิว:
กฎการอนุญาตควรกำหนดที่เดียว (เช่น canApproveInvoice) และ บังคับบน API UI แค่ซ่อน/ปิดการใช้งานการกระทำเท่านั้น
ปฏิบัติเหมือนแต่ละพื้นผิวเป็นเป้าหมายการสร้างแยกต่างหากที่ดึงแพ็กเกจร่วม:
ใน CI/CD ให้เรียงขั้นตอน: lint → typecheck → unit tests → contract tests → build → security scan → deploy และเก็บความลับ/คอนฟิกนอกรีโพ
ใช้ AI เหมือนวิศวกรจูเนียร์ที่เร็ว: ดีสำหรับร่าง แต่ไม่ควรนำขึ้นรวมโดยไม่ตรวจสอบ
เกราะป้องกันที่ดี:
ถ้าผลลัพธ์ AI ละเมิดกฎสถาปัตยกรรม ให้ปฏิเสธ แม้มันจะคอมไพล์ได้