Seal Courses/Domain-Driven Design in Practice
DDD Reference

Business Language, Models, Boundaries and Continuous Learning

Domain-Driven Design in Practice

คอร์ส Domain-Driven Design แบบครบวงจรสำหรับ Business, Product และ Engineering เริ่มจาก Business Domain, Subdomain และ Domain Experts แล้วประเมินความคุ้มค่า เรียนรู้ domain ร่วมกัน สร้าง Ubiquitous Language, Bounded Context และ Context Map แล้วพัฒนา model ด้วย Tactical DDD พร้อมนำไปใช้ตามบริบทตั้งแต่ small business ถึง corporate

31 บทเรียน6 partsSoftware Engineering

Course trail

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

Part 1 — Foundations and Economics

บทที่ 1Business Domains, Subdomains and Domain Expertsเข้าใจธุรกิจและผู้ถือความรู้ก่อนออกแบบ software พร้อมจำแนก Core, Supporting และ Generic จาก strategy จริงบทที่ 2Why DDD and When It Paysเชื่อม DDD กับ business outcome, cost of change และความเสี่ยง พร้อมรู้ว่าเมื่อใดไม่ควรลงทุนเพิ่มบทที่ 3Models as Working Theoriesเข้าใจ model ในฐานะสมมติฐานที่เลือกเพื่อแก้ปัญหาและต้องเปลี่ยนตาม evidence ไม่ใช่ภาพแทนโลกทั้งหมดบทที่ 4Ubiquitous Language in Practiceสร้างภาษาที่ใช้จริงใน conversation, examples, model, code และ tests พร้อมจัดการคำเดียวหลายความหมายบทที่ 5Complexity and Core Domain Strategyแยก business complexity, differentiation, criticality และ risk เพื่อจัดการลงทุน Core, Supporting และ Generic

Part 2 — Discover the Domain Together

บทที่ 6Collaborative Modeling in Practiceเลือก workshop ให้ตรงคำถามและเปลี่ยนความรู้หลายฝ่ายเป็น scenario, hotspot และ model hypothesisบทที่ 7Big Picture EventStormingสำรวจ timeline, pivotal events, policies, pain points และโอกาสของทั้ง value stream โดยไม่รีบออกแบบ softwareบทที่ 8Domain Storytelling and Scenariosให้ Domain Expert เล่า actors, work objects และ activities เพื่อเห็น handoff, responsibility และ language จริงบทที่ 9Example Mapping: Rules and Questionsเปลี่ยน story ให้เป็น rules, concrete examples, counterexamples และ questions ก่อนสร้าง model หรือ codeบทที่ 10From Discovery to Subdomainsสังเคราะห์ events, capabilities, language และ change patterns เป็น Subdomain hypotheses หลายทางเลือก

Part 3 — Bound Models and Relationships

บทที่ 11Bounded Contexts in Practiceกำหนดขอบเขตที่ model และภาษาหนึ่งสอดคล้องกันโดยไม่เท่ากับ service, team หรือ database อัตโนมัติบทที่ 12Context Mapping Relationshipsทำให้ upstream, downstream, power, translation และ collaboration cost ระหว่าง contexts มองเห็นและต่อรองได้บทที่ 13Bounded Context Canvasบันทึก purpose, language, business decisions, messages, assumptions, owners และ metrics ของ boundary hypothesisบทที่ 14Context Integration Patternsเลือก Partnership, Customer/Supplier, Conformist, ACL, Published Language หรือ Separate Ways ตาม relationship จริงบทที่ 15Teams, Cognitive Load and Ownershipเชื่อม model boundaries กับ team flow โดยไม่บังคับ Bounded Context และทีมให้เป็นความสัมพันธ์หนึ่งต่อหนึ่งบทที่ 16Fintech Domain Landscapeทดสอบ candidate contexts รอบ Customer Intent, Payment Execution, Ledger, Risk, Balance และ Reconciliation

Part 4 — Model Behavior in Code

บทที่ 17From Scenario to Modelเปลี่ยน examples เป็น behavior, state transition, invariant และ model alternatives ที่พิสูจน์ด้วย tests ได้บทที่ 18Entities and Value Objectsแยก identity กับ value semantics และทำ invalid state ให้สร้างยากผ่าน Money, Currency และ Transfer examplesบทที่ 19Aggregates and Invariantsออกแบบ consistency boundary จาก business invariant, concurrency และ failure ไม่ใช่จาก foreign-key graphบทที่ 20Services, Policies and Specificationsวาง business decision ที่ไม่เข้ากับ Entity ใด พร้อมแยก Domain Service จาก application orchestrationบทที่ 21Factories, Repositories and Modulesใช้ creation, persistence และ module boundaries เพื่อปกป้อง model โดยไม่สร้าง abstraction ครบชุดทุกจุดบทที่ 22Domain Events without Event Hypeแยก business fact, internal Domain Event, Integration Event, audit record และ Event Sourcing ออกจากกันบทที่ 23Tactical Modeling in Practiceประกอบ Tactical DDD patterns เป็น model เดียวจาก forces และลบ pattern ที่ไม่เพิ่มความชัด

Part 5 — From Model to Running System

บทที่ 24Application Boundaries and Transactionsรักษา domain decisions ภายใน model และให้ application layer ประสาน use case, transaction, authorization และ portsบทที่ 25Commands, Queries and Read Modelsแยก intent, decision และ display needs โดยไม่กระโดดไป CQRS infrastructure หรือใช้ read model ตัดสินเงินบทที่ 26Anti-Corruption Layer and Published Languageแปล semantics ที่ boundary และออกแบบภาษาสาธารณะซึ่งมี owner, version และขอบเขตข้อมูลชัดเจนบทที่ 27Reliable Domain Processesดูแล process ข้าม Aggregate/Context ด้วย identity, outbox, idempotency, compensation และ reconciliationบทที่ 28Event Sourcing Selectivelyประเมิน history, temporal query และ audit value เทียบกับ schema evolution, projection และ operational cost

Part 6 — Adoption and Evolution

บทที่ 29DDD by Company Contextเลือก practice ให้พอดีกับ small business, scale-up, corporate และ regulated Fintech โดยไม่ลอก enterprise ceremonyบทที่ 30Brownfield Adoption and Operating Modelนำ DDD เข้า legacy system ทีละ seam พร้อม cadence, ownership, metrics และเกณฑ์หยุดหรือขยายผลบทที่ 31Capstone: Money Transfer under Changeทำ discovery, strategy, context map, model, integration และ adoption plan ของ transfer ที่เปลี่ยน provider และ jurisdiction

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

คอร์สนี้เป็นคอร์ส Domain-Driven Design โดยตรง ไม่ใช่คอร์ส folder structure, Clean Architecture หรือ microservices ที่ใช้คำศัพท์ DDD เป็นคำนำ เราเริ่มจาก business problem, model และการเรียนรู้ร่วมกัน แล้วจึงตามผลของ model ไปถึง code, integration, team ownership และการนำไปใช้จริง

  • Part 1 เริ่มจาก Business Domain, Subdomain และ Domain Experts แล้วอธิบาย model, Ubiquitous Language, complexity และ economics ของ DDD
  • Part 2 ฝึก EventStorming, Domain Storytelling, Example Mapping และ Subdomain discovery
  • Part 3 สร้าง Bounded Context, Context Map, integration relationship และ ownership
  • Part 4 ลง Tactical DDD ผ่าน Entity, Value Object, Aggregate, Service, Policy, Repository และ Domain Event
  • Part 5 เชื่อม model กับ application boundary, read model, Published Language, reliable process และ Event Sourcing อย่างเลือกใช้
  • Part 6 ปรับระดับตามบริษัท นำเข้า brownfield และทำ Fintech capstone

ใครควรอ่าน

Business และ Product leaders ใช้คอร์สนี้เพื่อเลือก Core Domain และตรวจว่าการลงทุน modelling คุ้มกับ business outcome หรือไม่ Domain Experts จาก Operations, Finance, Risk และ Compliance ใช้ scenario, language และ policy ownership ทำให้ความรู้ไม่หายตอนส่งต่อ ส่วน Engineer, Tech Lead และ Architect ใช้ model เป็นฐานของ behavior, boundaries และ integration

ตัวอย่าง code ใช้ Go แต่ Part 1– 3 และแบบฝึก discovery ไม่ต้องมีพื้นฐานภาษา Go ผู้ที่ทำ Tactical DDD labs ควรอ่าน code backend และเข้าใจ transaction/database เบื้องต้น

Running Case: Money Transfer under Change

คอร์สใช้ Fintech platform สมมติที่ให้ลูกค้าส่งเงินผ่านหลาย provider และหลาย jurisdiction:

Concernคำถาม Domain
Customer Intentลูกค้าขอทำอะไร และ intent หมดอายุหรือถูกยกเลิกเมื่อใด
Eligibility/Riskใครตัดสิน ใช้ policy version ใด และผลมีอายุเท่าใด
Funds Availabilityยอดใดใช้อนุมัติการใช้เงิน และ consistency ต้องเป็นแบบใด
Payment Executionprovider รับคำสั่งหรือยัง และ timeout หมายถึง failed หรือ unknown
Ledger/Accountingfinancial facts ใดถูกบันทึกและแก้ด้วย action แบบใด
Reconciliationinternal records ต่างจาก provider/bank อย่างไรและใครซ่อม
Customer Displayหน้าจอแสดงอะไร สดแค่ไหน และห้ามใช้ตัดสินอะไร

รายชื่อเหล่านี้เป็น candidate concerns ไม่ใช่ Context Map มาตรฐานของ Fintech ผู้เรียนต้อง ใช้ language, policy, lifecycle, consistency, ownership และ change pattern ทดสอบทุก boundary

Policy และจำนวนเงิน

จำนวนเงินใช้ integer minor unit พร้อม Currency เสมอ ส่วน KYC threshold, transfer limit, retention, maker-checker และ compliance policy ต้องมาจาก accountable owner หรือ regulator พร้อมชื่อ source, version, jurisdiction และ effective date Engineer ห้ามคิดค่าขึ้นเอง

[!WARNING] Decision Path กับ Display Path read model หรือ cache ใช้แสดงผลได้ตาม freshness contract แต่การอนุมัติ transfer ต้องกลับไป ให้ context เจ้าของ authoritative state ตรวจ invariant ภายใต้ consistency/concurrency boundary ที่ตกลงไว้ DDD ไม่ได้ทำให้ระบบ compliant หรือ financial-correct โดยอัตโนมัติ

ขอบเขตของหลักฐาน

คอร์สใช้ DDD Reference ของ Eric Evans เป็น vocabulary authority ใช้ EventStorming, Domain Storytelling, Example Mapping และ DDD Crew เป็น collaborative practices ใช้ official AWS/Microsoft guidance เป็น implementation evidence และใช้ first-party cases ของ Uber, Stripe, Monzo กับ Adyen เป็นตัวอย่างตามบริบท

แหล่งเหล่านี้ยืนยันว่าแนวคิดถูกใช้ในองค์กรจริง แต่ไม่ใช่ market-share survey หรือ causal proof ว่า DDD ให้ ROI เท่ากันทุกบริษัท ทุกบทจึงแยก:

  1. Definition/Pattern — นิยามหรือ pattern จากต้นทาง
  2. Heuristic/Trade-off — แนวตัดสินที่ต้องมีเงื่อนไขและข้อยกเว้น
  3. Course Convention — รูปแบบ lab ที่เลือกเพื่อการเรียนรู้

สิ่งที่ต้องทำได้เมื่อเรียนจบ

  • ตั้งคำถามและเรียนรู้ domain ร่วมกับผู้รู้จริง
  • อธิบาย Business Domain, Subdomain และ Domain Expert โดยไม่สับสนกับ software component
  • สร้าง Ubiquitous Language ที่ใช้ใน conversation, examples, code และ tests
  • เสนอ Subdomain/Bounded Context หลายทางเลือกและทดสอบด้วย counterexample
  • เลือก Context Map relationship ตาม power และ translation cost
  • ใช้ Tactical DDD เท่าที่ช่วย model โดยไม่สะสม pattern
  • แยก customer intent, financial decision, execution, ledger, display และ reconciliation
  • นำ DDD เข้า legacy system ทีละ seam และวัดว่า flow/correctness ดีขึ้นจริงหรือไม่
  • ปรับ practice ให้พอดีกับ small business, scale-up และ corporate/regulated context

Reading Backbone

รายละเอียด claim-to-source และ currentness policy อยู่ใน research note ของคอร์ส