จดๆจาก Software Architecture Meetup 2026

Redproof, Anti-Rot: Gate What You Care

Speaker Salah Chalermthai

📌สำหรับ Talk นี้ Speaker จะมาเล่า ทำ Software ให้เราเข้าใจ และไม่ Vibe โดยที่ไม่รู้อะไร โดยมีนเกิดจากปัญหา Abstraction Mismatch เนื่องจาก Prompt ที่เราป้อนมักเป็น High-level แต่โค้ดที่ AI กลับเป็น Low-level

📌การแก้ ต้องทำ Ubiquitous Language / การวาง Domain Boundary เพื่อที่จะได้ review ระดับ Contract / Abstraction Layer ที่ชัด เห็น Code ที่สื่อ

สิ่งที่เราควรทำหละ ทำให้ภาษาเดียวกันทั้งในส่วนของ What / How

📌One Commit per Bounded Context - ให้ Agent รวบ แล้วเรา Review ทั้งหมดในส่วน Domain นั้นได้เลย คนไม่ Overload ด้วย

📌Deep Module Testing ซึ่งเน้นทดสอบผ่าน Public Interface ตาม Behavior โดยไม่ใช้ Mock หนักๆ Component Testing เพราะ Unit Test ลึกไป ส่วน E2E Test เตรียมการเยอะไป

📌Technical Debt ในยุค AI มันไม่น่าจะใช้เป็นข้ออ้างได้แล้ว มันเกิดจากเราคุม Agent ไม่ดี จนได้สัตว์ประหลาดตัวใหม่มากกว่า เป็น Check List จะมี 3 อย่าง

• รู้ว่าภาพรวมการทำงาน - Taste ในส่วน Architecture
• รู้ว่าเราทำอะไรอยู่
• รู้ว่าจะตรวจยังไง คุมยังไง - Guardrails

📌ถ้าเราอยากคุมคุณภาพจะมีตัว Feed Forward and Feedback ซึ่งมีส่วนของ

• Guide - Skills หรือ Prompts ที่เราป้อนเข้าไปเพื่อสั่งให้ AI Agent
• Sensors - เครื่องมือที่ใช้ตรวจ ว่ามันถูกต้องไหม เป็น Safety Net ยกตัวอย่าง เช่น Linter / Tests / Dependency-crusier แต่มีปัญหา
  - Lack of Composition ทำงานแยกกัน เลยไม่เห็นภาพรวม มันเชื่อมกับ Biz / Arch ยังไง
  - Custom Script มันเสียเวลา และยุ่งยาก
  - Who Tests the Guardrail?

ความยากโลกนี้มี Skill มากไป แต่ Senors ไม่พอ

เลยเป็น Idea ของ Speaker มาทำ Tools RedProof ที่มาช่วย คิดแบบ Logical

• ต้องการ Gate อะไร เช่น
  - Arch เช่น Functional Core Imperative Cell – Pure ไม่มี IO Side Effect / Exception Flow ต้องไม่ให้ AI มาเพิ่ม)
  - API เช่น ตาม Contract/ Schema
  - Testing งานบน CI 10 นาที
  - Doc เป็นต้น
• กำหนด Rule - เงื่อนไข หรือ Policy ที่เป็นจริงเสมอ
• Check: ตัวทดสอบว่าระบบผ่าน Rule หรือไม่ ซึง Framework มันรองรับ 2 แบบ
  - เอา Tools เดิมมาเชื่อม
  - ใช้ Composition API - มองเป็น Block แล้วสร้างมันขึ้นมา
• Proof: การทดสอบ Guardrail Mutation Testing โดยตั้งใจ Inject False เพื่อดูว่า Guard Rail ยังทำงานถูกต้องไหม (Green) ถ้าถูกแสดงมีช่องโหว่ ต้องมาเพิ่ม Test Case เพื่อดักเป็น Red

ด้านในมี Command หลักๆ describe, check, proof ลองไปแงะใน Repo เอา ซึ่งถึงนึกไม่ออกว่าจะเริ่มยังไง ลองใช้ Skill (Discovery, Design, Build, Challenge, PR Review) มาแนะนำได้

Q&A

• Rule ควรเป็น True/False ไหม ? แล้ว Refuse คือ อะไร
  - Rule ต้องเป็น True
  - Refuse ช่วยป้องกันปัญหา False Alarm ในคนเข้าไปตรวจ
• Speaker - ยังต้องเข้าไปอยู่ใน Loop การพัฒนาและตัดสินใจในแต่ละจุดมากน้อยแค่ไหน?
  - อยู่ นอก Loop สร้าง Software Factory สิ่งที่ต้องทำจับเรื่อง What + How สื่อสารได้ตรงกัน ควบคุมระดับ High-Level บน Dashboard เช่น การดูแล Domain Boundary, Context Mapping, และ Public Contract ของระบบ โดยสร้างทั้ง Prompt, Skill และ Sensor (Guardrails)

Resource: https://github.com/schalermthai/redproof

Applying Category Theory with Domain-Driven Design

Speaker Chakrit Riddhagni

Category Theory นอกจาก Type หรือ Monad ในมุมของ Dev แล้ว มันช่วยให้เรา Map ความคิดได้นะ

What is a Category Theory

📌ก่อนเข้าใจ Category Theory มาลองดูที่ทุกคนน่าจะเข้าใจกันก่อนกับ Set Theory เป็นเรื่องการให้เหตุผล โดยไม่จำเป็นต้องรู้จักทั้งหมด เช่น ภาษาอักษร กับภาพ / สัตว์ 4 ขา กับ สัตว์เลี้ยง เป็นต้น

📌Category Theory - การอธิบายวิธีการให้เหตุผลของคนเรา โดยมีการนิยามจาก

• Objects ของที่สนใจ
• Morphisms ความสัมพันธ์ของ Object ว่าจะไปทางไหน หรือ แค่รู้จักกัน สำคัญสุดนะ

เช่น การแสดงความสัมพันธตัวเลข หรือ ครอบครัว

ถ้าเราสามารถ Abstraction ในรูป Objects + Morphisms เราการให้เหตุผลของเราได้หมด ตัวที่บอกมัน Make Sense ต้องมาดู Property อย่าง

• Composition การให้เหตุผล มี Morphisms อธิบายได้ จาก A > B เช่น
  - นั่ง MRT จากเพชรบุรีไปพระราม 9 แล้วต่อไปศูนย์วัฒนธรรม สามารถ Compose เป็นการเดินทางจากเพชรบุรีไปศูนย์วัฒนธรรมได้
  - ถ้าแบบในข่าว A รู้จักกับ B คุยกัน แต่ A ไปบอกว่าไม่รู้ ไม่รู้ อันนี้ Composition จะพังนะ
• + Identiy อันนี้เวลาจำกัดพี่คริสเลยไมใด้ ลองไปอ่านเพิ่มดู อะไรวนกับมาเป็น Objects ตัวเอง ไม่มี Side Effect

What is a Functor (Covarient)

📌Functor ซึ่งคือการ Map ระหว่าง Category หนึ่งไปยังอีก Category โดยมีกฏ

1. Map ทุก Objects
2. Map ทุก Morphisms
3. Preserve Identity
4. Preserve Composition - ไม่จำเป็น 1-1

ตัวอย่าง Category การเดินทาง MRT กับ Category "ร้านอร่อยประจำสถานี" ตัว Functor เอาการให้เหตุผลของ Category ไปใช้กับอีก Category MRT <-> ร้านอร่อย

📌Functor ใน Programming Haskel ตัว MayBe / Optional / List ก็เป็นนะ มี .map() คอยรักษา Morphism ไว้ และเราไม่ต้องเรียนรู้อะไรเยอะ ใช้เหตุผลเดิมได้ มันจะต่างกับ การทำ Equal เป็น Generic ไม่ใช่ ต้องคิดและเขียน Logic ใหม่.

Domain-Driven Design (DDD) เกี่ยวยังไง ?

📌Business Domain สามารถมองเป็น Category
📌System Architecture/Code ก็มองเป็น Category

อยากเข้าใจ Domain > อ่าน Code ได้ง่าย สิ่งที่ต้องทำ Functor มีรูปแบบ

• Ubiquitous Language Functor Map คำนาม -> Object, คำกริยา -> Method/Event ต้อง Preserve Structure ให้ผลลัพธ์ตรงกับ Business Domain
• CRUD Functor(ทางเดียว Domain > Code) Map ทุก Morphism ลงมาเหลือเพียง Create, Update, Delete บน Object เดียว

Domain-Driven Design เป็นเพียง Functor ที่เชื่อมระหว่าง Category of Business Domain ไปยัง Category of System Architecture Key เราต้องหา Functor ทีดี
- หา Morphisms ที่ trigger เปลี่ยน State
- Simple

Q&A.

• ในกรณี Payment เป็น Object Payment แล้วมี method pay() ซึ่ง Returnเป็น Object Payment เดิมแต่เปลี่ยนสถานะภายใน จะทำได้ไหม?
  - ทำได้อาจทำให้ Functor หรือ กฎในการ Map ซับซ้อนเพิ่มขึ้นเป็น Trade-off ระหว่างการมีจำนวน Type ในระบบน้อย กับความซับซ้อนของกฎการแมปที่เพิ่มขึ้น

Extreme Discussion

Speaker Chakrit Riddhagni / Thai Pangsakulyanont / Natechawin Suthison

📚 Software Design vs Software Arch มันต่างกันยังไง

• ส่วนใหญ่มองว่าทับซ้อนกัน ตามวิชาเรียน Software Design and Architecture
• แต่มองอีกมุม
  - Software Design คือ Process หรือกระบวนการคิด
  - Software Architecture คือ Pattern ที่ค่อย ๆ เด่นชัดขึ้นมา (Emerge) จากการทำซ้ำ ๆ

📚 ทุกวันนี้คงไม่มีใครเขียน Program เองแล้ว และระบบเก่าๆ เราจะการยังไง อะไรที้เรา keep abandon

สิ่งที่จะ Keep ไว้

• Ubiquitous / Domain Language ระหว่างคนกับ AI เพื่อไม่ให้ AI หลอน
• Boundaries ลด Context ของ AI ให้ชัด
• Verifiable Loop / Guardrails - AI ทำให้ของยากง่ายขึ้น อย่าง RedProof, Mutation Testing, Formal Verification
• Resiliency Patterns รูปแบบอย่าง Atomic operations, Idempotency, State Machine เราสามารถถกกับ AI และให้มันใส่ได้เลย

สิ่งที่จะ ปรับเปลี่ยนไป

• เลือก Stack ที่ Deterministic อย่างตัว Angular มัน CLI เลยทำให้ Code มี Pattern ทำให้ AI มันมีข้อมูลที่ดีแนะนำ จะต่างกับ React ที่มีหลากหลายแบบ
• การทำละนิด AI มันไว เราสามารถลองหลายๆแบบ จะจบใน Sprint เดียวได้

📚 ถ้าเป็น Consultant แล้วเวลาในการออกแบบ structure ไม่มากพอ เราพอจะมีวิธีคิดหรือ หาสิ่งที่เหมาะสมยังไงให้ไวและคงสามารถ ma ระบบได้ไม่พังในอนาคต

• มองก่อนว่าสุดท้ายเราต้องการโจทย์อะไร เช่น Redundancy แล้วมาหา Solution Trade Off ตามเวลา หรือ ข้อมูลที่ได้ เช่น มี Evo ในอนาคต
• ยึดหลัก YAGNI (Do the minimum that solves the problem)

📚 ในฐานะที่ผมอยู่ในระดับ Junior อยู่ คิดว่าอนาคตจะมีวิธีการออกแบบระบบใหม่ ๆ บ้างมั้ยครับ นอกเหนือจากที่มีในปัจจุบัน

• เริ่มจากระบบเล็ก มีความอยากรู้ (Curiosity) สะสมประสบการณ์ ความเจ็บปวด 55 และขยับมา โดยใช้ AI เป็นคู่คิด และ Second Opinion ลองสิ่งใหม่ๆ เมื่อก่อนเวลาน้อย อาจจะลองได้ทีละอัน คราวนี้มี AI ลองสัก 2 ทางได้
• ตอบให้ได้ก่อนว่า Context / Design เพื่ออะไร มี Constraints อะไรจำกัด แล้วเกิด Trade Off ยังไง
• Reflect จับจุดที่มัน Common ดูว่ามี Learning Sign เปลี่ยนแล้วเกิดผลอะไร / อนาคตมันจะเป็นยังไง

📚 Team culture เปลี่ยนไปเยอะมั้ยหลังใช้ AI เช่น คนคุย AI มากกว่าถามกับทีม กับคน กลายเป็น domain knowledge จากการทำงานไม่ถูก discuss เท่าเมื่อก่อน

Throughput เพิ่มขึ้นทำให้การ Sync แบบเดิมๆ อาจจะทำไม่ทัน มีแนวทางที่ควรลอง

• Multiplayer Coding Session: แชร์ Session การ Prompt /คุยกับ AI ให้ทีมเห็น ใน Cursor มีแล้ว
• เน้น Communication Flow มากกว่า พิธีกรรม (Ceremony) พวก Standup Meeting
• เอา AI มาช่วย Recap แต่ยังต้องนำสิ่งที่ AI ให้มา Validate และ Sync ร่วมกัน เพื่อเปลี่ยน Personal KM ให้กลายเป็น Shared Understanding ของทีม

📚 Software Architect / Architecture ที่ดีหน้าตาไปเป็นไง

• No Silver Bullet ทำให้ Fit กับ Context, Constraint และ Objective ของระบบ ณ ตอนนั้น ทำในสิ่งที่ตอบ Yarn ความต้องการ
• ออกแบบ Under Engineer อยู่เล็กน้อย เพื่อให้มทมีจุดที่ Improve ดีกว่า Over Engineer ไปแต่ใช้จริงลำบากจุดสังเกต Over-Engineer แก้แล้วไม่คุ้ม ทำซ้ำบ่อยเกินความจำเป็น
• Architect - ต้องสังเกตุว่ามันควรจะทำอะไรบ้างอย่างไร เช่น Cleanup / Refactor

มี Live ด้วขอบคุณทืมงาน และ Speaker ทุกท่านครับ

Reference

• https://www.eventpop.me/e/180913/sam