Seal Courses/DDD & Code Architecture in Practice
DDD Reference

From a Small Go Module to Enterprise Fintech

DDD & Code Architecture in Practice

คอร์สสำหรับ engineer ที่ต้องเปลี่ยน Domain-Driven Design จากศัพท์และ diagram ให้เป็นการตัดสินใจใน codebase จริง เริ่มจาก Ubiquitous Language, Subdomain และ Bounded Context แล้วค่อยเลือก Transaction Script, Layered Architecture, Rich Domain Model หรือ Ports & Adapters ให้เหมาะกับแต่ละ module พร้อมตัวอย่าง Go จากระบบ Fintech ระดับองค์กร

25 บทเรียน5 partsArchitecture

Course trail

เส้นทางการเรียน

Part 1 — Architecture Starts with the Domain

บทที่ 1DDD Is Not a Folder Structureแยก domain, model, code architecture, folder structure และ deployment boundary ก่อนเลือก pattern ให้ตรงปัญหาบทที่ 2Discovering the Domainเปลี่ยน business journey ให้เป็น scenario, command, event, policy, invariant และ Ubiquitous Language ก่อนออกแบบ codeบทที่ 3Core, Supporting and Generic Subdomainsจำแนกความได้เปรียบทางธุรกิจออกจาก criticality และ compliance risk เพื่อเลือกการลงทุนให้ถูกจุดบทที่ 4Bounded Contexts and Ownershipหา language, model, policy และ ownership boundary โดยไม่รีบเท่ากับ microservice หรือ databaseบทที่ 5Enterprise Fintech Landscapeสร้างแผนที่สมมติฐานของ Wallet, Checkout, Billing, Payment Integration และ Web Portal อย่างมีหลักฐาน

Part 2 — Choosing Code Architecture

บทที่ 6Architecture Decision Heuristicsประเมิน complexity, change, consistency, integration, risk และทีม เพื่อเลือก architecture แบบมี exit criteriaบทที่ 7Transaction Scriptใช้ flow ตรงไปตรงมากับ business logic เรียบง่าย พร้อมรู้สัญญาณว่าเมื่อใด pattern เริ่มรับภาระไม่ไหวบทที่ 8Layered Architectureแยก transport, application และ persistence ตาม responsibility โดยไม่สร้าง global technical layer ที่ผูกทุก featureบทที่ 9Rich Domain Modelใช้ Entity, Value Object, Aggregate และ invariant เมื่อ state กับกฎธุรกิจเปลี่ยนร่วมกันอย่างซับซ้อนบทที่ 10Ports & Adapters, Onion and Cleanแยก lineage และ vocabulary ของ 3 แนวทาง แล้วออกแบบ payment ports จากฝั่งผู้ใช้จริง

Part 3 — Organizing the Codebase

บทที่ 11Package by Type vs Package by Featureเปรียบเทียบ global technical folders กับ business slices ผ่าน cohesion, coupling และ locality of changeบทที่ 12Small Single-Domain Codebaseเริ่ม codebase เล็กด้วย package เท่าที่จำเป็น และเพิ่ม seam เมื่อมี growth signal ที่สังเกตได้บทที่ 13Rich Single-Module Codebaseวิวัฒน์ business slice เดียวให้รองรับ domain rules, use cases, ports และ adapters โดยไม่แตก package เกินแรงจริงบทที่ 14Large Multi-Module Codebase: Billingแบ่ง Billing ด้วย capability, lifecycle, invariant และ ownership พร้อม contracts และคำถาม boundary ที่ยังไม่ปิดบทที่ 15Naming Modules with Ubiquitous Languageเลือก invoice หรือ invoicing จากความหมายและ ownership ไม่ใช่กฎ tense พร้อมกำจัดชื่อกำกวมอย่าง utils และ coreบทที่ 16Hybrid Modular Architectureใช้ business capability เป็นโครงนอกและ architectural roles ภายใน slice พร้อม composition root และ import rules

Part 4 — Boundaries, Data and Integration

บทที่ 17External Payment Providers as Adaptersออกแบบ PaymentGateway แบบ vendor-neutral และแปล lifecycle, error กับ ambiguous outcomes ที่ Anti-Corruption Layerบทที่ 18Persistence and Data Boundariesแยก domain, persistence, write/read model และ cache โดยใช้ MySQL กับ Redis ตาม authoritative responsibilityบทที่ 19Identity, Authentication and Authorization Boundariesแยก identity protocol, Principal, use-case permission, ownership, domain policy, tenant isolation และ auditบทที่ 20HTTP, Webhook and Messaging Adaptersแปลง transport contracts เป็น application commands พร้อม authenticity, deduplication และ out-of-order handlingบทที่ 21Reliable Cross-Boundary Workflowsวาง idempotency, outbox/inbox, retry, Saga, Process Manager และ reconciliation เพื่อรับ crash และผลลัพธ์กำกวม

Part 5 — Enterprise Fintech Architecture

บทที่ 22Product and Context Mapทบทวน Wallet, Checkout, Billing และ Payment Integration เป็น ownership/contracts map พร้อม trace journey ข้าม contextsบทที่ 23Web Portal, BFF and Read Compositionออกแบบ Portal เป็น channel ที่ compose reads และส่ง commands กลับ owning context โดยไม่ join authoritative tablesบทที่ 24Testing and Architecture Fitnessวาง test ตาม seam ที่พิสูจน์ claim และ automate dependency, cycle, vendor containment กับ data ownership rulesบทที่ 25Evolution and Capstoneวิวัฒน์ architecture จาก module เล็กสู่ enterprise boundaries และส่งมอบ capstone journeys พร้อม ADR และ trigger

วิธีอ่านคอร์สนี้

คอร์สนี้ไม่ได้เริ่มจากการสร้างโฟลเดอร์ domain, application และ infrastructure แต่เริ่มจากการหาว่า ธุรกิจกำลังแก้ปัญหาอะไร ใช้ภาษาอะไร มีกฎใดห้ามผิด และใครเป็นเจ้าของการเปลี่ยนแปลงนั้น เมื่อคำตอบเหล่านี้ชัด เราจึงค่อยเลือก code architecture ที่มีต้นทุนเหมาะกับปัญหา

  • Part 1 สร้าง vocabulary และ boundary ระดับ Strategic DDD
  • Part 2 เปรียบเทียบ Transaction Script, Layered Architecture, Rich Domain Model และ Ports & Adapters จากแรงที่เกิดขึ้นจริง
  • Part 3 เปลี่ยนการตัดสินใจเป็น Go package และ folder structure ตั้งแต่ codebase เล็ก ไปจนถึง Billing ที่มีหลาย module
  • Part 4 ลงมือออกแบบ database, cache, Payment Gateway, authentication, authorization, webhook และ workflow ที่ข้าม boundary
  • Part 5 รวม Wallet, Checkout, Billing, Payment Integration และ Web Portal เป็น enterprise Fintech case study

สถานะการเผยแพร่

คอร์สนี้เขียนครบ 5 Parts รวม 25 Chapters แล้ว ทุกบทผ่าน content check, build และ browser rendering เมนูจึงแสดงครบตั้งแต่ Domain discovery ไปจนถึง enterprise Fintech capstone โดยไม่มีบท placeholder

สิ่งที่คอร์สนี้ต้องการให้คุณทำได้

เมื่อเรียนจบ คุณควรอธิบายได้ว่าเหตุใด module หนึ่งใช้ Transaction Script แต่อีก module ใช้ Rich Domain Model และเหตุใดการมี Bounded Context ไม่ได้แปลว่า ต้องแยก microservice ทันที คุณควรออกแบบ consumer-owned port สำหรับ database หรือ external provider ได้โดยไม่ให้ vendor DTO รั่วเข้า business model และรู้ว่า authentication, use-case authorization, resource ownership กับ domain invariant เป็นคนละความรับผิดชอบ

ตัวอย่างใช้ภาษา Go แต่เป้าหมายคือทักษะการตัดสินใจ ไม่ใช่การจำ template ผู้อ่านควรคุ้นเคยกับ HTTP API, relational database และการเขียน backend service มาก่อน ไม่จำเป็นต้องเคยทำ DDD

Running Case Study

เราจะค่อย ๆ วิเคราะห์ platform สมมติของบริษัท Fintech แห่งหนึ่ง:

Areaคำถามที่ใช้ค้นหา boundary
Walletใครเป็นเจ้าของ account, ledger, transfer และกฎของ balance
Checkoutcheckout session กับ payment attempt มี lifecycle อย่างไร
Billingsubscription, usage, invoice, credit note, receivable และ receipt ควรแบ่งอย่างไร
Payment Integrationapplication จะคุยกับ provider โดยไม่ผูก domain กับ vendor ได้อย่างไร
Web Portalเป็นเพียง channel/BFF หรือมี business capability ที่เป็นของตัวเอง

รายชื่อนี้เป็น สมมติฐานเริ่มต้น ไม่ใช่คำตอบว่าแต่ละกล่องคือ Bounded Context บทเรียนจะใช้ language, invariant, lifecycle, data ownership และ change pattern เป็นหลักฐานในการยืนยันหรือแก้ boundary

Technology Is Evidence, Not the Curriculum

  • ใช้ MySQL แสดง authoritative persistence, transaction, constraint, concurrency และ repository integration test
  • ใช้ Redis แสดง derived state, cache, read model, TTL และ invalidation
  • ใช้เอกสารทางการของ Stripe เป็นตัวอย่าง payment lifecycle, integer minor unit, idempotency, ambiguous failure และ webhook delivery
  • ใช้ PaymentGateway เป็น application-owned abstraction โดยไม่สร้างบท “Implementing Stripe Adapter” หรือผูก architecture กับ vendor รายเดียว
  • อ้าง Temporal เมื่อจำเป็นต้องอธิบาย orchestration boundary ส่วนรายละเอียด SDK อยู่ในคอร์ส Temporal for Fintech

Authoritative state กับ display state

Redis หรือ composed read model อาจเหมาะกับหน้าจอที่ยอมรับข้อมูลเก่าได้ แต่การอนุมัติ Transfer, Refund หรือการตัดสินใจที่เปลี่ยนเงินต้องอ่านจาก authoritative state และตรวจ invariant ภายใน boundary ที่เป็นเจ้าของกฎ การเลือกแหล่งข้อมูลต้องถูกระบุเป็นส่วนหนึ่งของ use-case contract

Evidence Labels

คอร์สแยกข้อความสำคัญเป็น 3 ชนิด:

  1. Definition/Pattern — อ้างต้นทาง เช่น Eric Evans, Martin Fowler หรือ Alistair Cockburn
  2. Heuristic/Trade-off — บอกเงื่อนไข ข้อยกเว้น และสัญญาณที่ควรทบทวน
  3. Course Convention — รูปแบบที่เลือกเพื่อให้ตัวอย่าง Go สม่ำเสมอ แต่ไม่อ้างว่าเป็นมาตรฐานสากล

ตารางอย่าง Core → Rich Domain Model จึงใช้เป็นจุดเริ่มสนทนา ไม่ใช่สูตรสำเร็จ Core หมายถึงความได้เปรียบของธุรกิจ ขณะที่ operational criticality, security, compliance และ consistency เป็นอีกชุดแรงที่ต้องพิจารณาแยกกัน

Business policy ต้องมีเจ้าของ

เพดานธุรกรรม, KYC threshold, maker-checker rule, retention period และข้อกำหนด compliance ต้องมาจากเจ้าของที่รับผิดชอบหรือ regulator พร้อมชื่อ เอกสาร และวันที่ ตัวอย่างในคอร์สมีไว้สอนตำแหน่งของ policy ใน architecture ไม่ใช่กำหนด policy ให้ระบบจริง และการใช้ pattern ใดไม่ได้ทำให้ระบบ “ผ่าน PDPA/PCI” โดยอัตโนมัติ

Reading Backbone

แต่ละบทจะเพิ่ม primary source ที่เกี่ยวข้องกับ claim ของบทนั้นโดยตรง