[KBTG-GO#02] Software Design

อันนี้เน้นจด Keyword เหมือนเดิม หัวข้อประมาณนี้ เกือบลืมสารบัญ 55

1. Software Development Approach

• Code First
  - เหมาะทีมเล็ก เน้น Deliver ไว ทดสอบตลาด
  - แต่ไม่ Maintainable Doc / Test / Decision Note / แต่บางครั้ง Solution ไม่สอดคล้องกับปัญหา แก้ได้ แต่ไม่ยั่งยืน
• Design First
  - Share Understanding กับทุกคน ที่เกี่ยวกับ App สร้างข้อตกลง (Decision) เกิดการสื่อสาร มี standard ร่วมกัน และลดความเสี่ยง ทำให้เห็นภาพรวม
  - ใช้เวลาเยอะในช่วง Initial
  ตัวอย่าง USB ที่ตอนนี้มีเป็นมาตรฐานจริงๆ

Problem Domain alight with Solution Space

2. Design Step

Understand the problem 
   > Clarify requirement + Define Scope 
      > High Level Design  
         > Proposal & Validation 
            > Deep Drive Design

• Understand the problem + persona รู้บริบท / เข้าใจ Context ทำ research มานะ
• Clarify requirement ทำปัญหาให้ชัดเจน
  + Define Scope จัดลำดับความสำคัญ อะไรควรทำก่อน และกำหนดขอบเขต
• High Level Design คุยทั้งทีม ให้เข้าใจ เห็นภาพรวมกัน Tech / Non-Tech
• Proposal & Validation ให้ stake holder (คนจ่ายเงิน คนอนุมัติ) มาร่วม และตรวจสอบ ถ้าผิดแก้เลย บอก Trade-Off
• Deep Drive Design ลงไป Design แต่ละ Module Service ได้พวก ADRS / Threat Modeling
  และค่อยลงไปในแต่ละส่วนย่อย API

จากนั้น Iterative Increment Design วนซ้ำ

3. Visual Modeling Language Design

• Why ทำให้เห็นภาพ เกิดความเข้าใจตรงกับ ถ้าสงสัยอะไร ถาม และพูดคุย
• Visual Language
  - UML - Activity Diagram (High Level) / Sequence Diagram(Low Level - message/method call)
  - ฺBPMN
• Tools
  - PlantUML
  - Mermaid - Mark Down Style
  - mingrammer เพิ่งรู้ว่ามีตัวนี้แหะๆ

สงสัยตัว PlantUML มีคนใช้ไหม หลังๆ ผมใช้ Draw.io / excalidraw / Mermaid ตัวหลังผมมองว่า DiagramAsACode

4. API Design at First

• API first - บอกว่า Actor ทำอะไรกับ API ให้มองเหมือน Use Case ใครกับอะไร ส่วนนั้นจะส่วนที่จัดการ Business Logic สมัยนี้จะในมุมของ REST API เป็นหลัก
• OpenAPI
  - มาตรฐานกลางในการอธิบาย API //Dev ขี้เกียจทำ Doc อ่านะ 555
  - นอกจากทำ Doc แล้ว เอามา Generate Code ด้วย
• Swagger Tools Implement ตามมาตรฐานข้อง OpenAPI โดยสามารถ
  - UI ไว้ Expose ว่าเรามีอะไรออกไป เป็นทั้ง doc / test tools เลย
  - Generate จาก yaml ของ openapi มาเป็น Code //อันนี้ไม่เคยใช้เลย พวก Gen Code เพิ่งรู้ว่ามีด้วย
  Plug-In มีหลายอันนนะ อย่างของ VS Code มี OpenAPI (Swagger) Editor - Visual Studio Marketplace

5. N-Tier Archtecture

• N-Tier N = จำนวนใคร ปกติจะ 2 / 3 Tier
• Tier แบ่งหน้าที่ของ Application
• ส่วนใหญ่จะแยกเป็น 3 Tier
  -Presentation Tier พวก Frontend web อย่าง Vue / Angular / React
  -Logic Tier พวก backend dotnet spring
  -Data Tier พวก DB / Object Storage

อ๋อแล้วมีของ N-Layer อย่างใน Spring แยก Controller(Presentation) / Service(Logic) / Repository (Data) มัน abstraction ไปอีกมุมนึง

Note Tier = Physical / Layer Logical

6. Operational Model

มีหลายแบบ ตอนนี้ที่ใช้กันเด่นๆ มี 4 แ

1. API - ข้อตกลงในการทำงาน ส่วนใหญ่ตอนนี้จะเป็น REST (JSON/XML) ทำงานตาม Request
2. Batch - ประมวลผลข้อมูลเป็นรอบๆ
3. Event-Driven - งาน Asynchronous ตาม Event โดยอาจะมีพวก message queue มาใช้ ตัวอย่าง พวก Serverless / งาน Notification
4. Streaming - เอาข้อมูลเล็กมาประมวลผล เรื่อยๆ แบบ (Near) Real-Time

7. Monolithic Architecture

Keyword

• Scale-Up (Vertical) เพิ่ม Spec
• Scale Out (Horizontal) เพิ่ท HW / Instance + Availability
• Coupling Cohesion
  มี Blog - Cohesion VS Coupling | naiwaen@DebuggingSoft

Monolithic Architecture

Single Code Base + Deployment เมื่อเอาไป Run บน Process เดียวกัน

• ข้อดี ตอนแรกที่ Simple + Tech Stack เดียวกัน รวมของตาม Coupling Cohesion (ถ้าวาง Code Structure ดี)
• ข้อเสีย Scale ได้ เพิ่ม web ได้ แต่ไปตายที่ DB //จิงทำได้นะ ส่วนตัวเคยใช้ท่า replication

Monolithic ไม่ได้แย่นะ หลายที่ใช้อยู่ และ รับ load ได้เยอะ

• StackOverflow
• Under Deconstruction: The State of Shopify’s Monolith

8. Service Oriented Architecture (SOA)

มองภาพของระบบตาม Service (Service Base) แต่อาจจะมีข้อกำหนดบางอย่างเพิ่มมา เช่น Data Dulplication โดยเจ้า SOA

• ข้อดี ยึดหยุ่น เลือก Tech พัฒนาได้ไว / Scale ได้ดี
• ข้อเสีย Enterprise Service Bus (ESB) เป็นตัวกลางให้ Service สื่อสาร อาจจะด้วย Protocol เอง หรือตัว ESB ที่ทำให้ช้า และเป็นต้วที่ล่มเสียเอง

9. Microservice

มองภาพของระบบเป็น Servive เหมือน SOA แต่พยายาม

• ให้ขนาดเหมาะสม ตอนนี้จะเน้นแบ่งตาม Domain จาก Domain Driven Design
• แยก Database ของแต่ละ Service ออกจากกันด้วย (Scale + Availability)
• การสื่อสาร จากเดิม SOA ต้องผ่านตัว ESB เสมอปรับเป็น
  - ให้แต่ละ Service คุยกันเองได้
  - มีตัวอย่าง อย่างตัว Message Broker + Message Queue ให้เพื่อลด coupling
• ออกแบบเพิ่มให้รับเรื่องการ Fail บางส่วนได้ (Fault Isolation)
• Process แยกออกจากกัน
• Tech Stack หลากหลายได้ โดยมี Protocol กลางในการสื่อสาร เช่น REST / GRPC
• High Cohesion (ตัว Service Domain เดียวกัน อยู้ด้วยกัน)  & Low Coupling (Dependency ระหว่าง Service)
• Deploy & Scale
• ยอมให้มี Data Duplication + ยอมลด Degree ของ Transaction แบบใน Database

แต่อาจจะมองว่าเพราะเทคโลยีดีขึ้น SOA เลย Rebrand เป็น Microservice 555

10. Microservice (Migration)

1. Monolithic - เกิดปํญหา มาหาสาเหตุก่อน จากพวก Monitor + Observability
2. Monolithic
   - Scale เข่น Code เดิมเพิ่ม Database หรีอ ทำ Caching
   - หรือ แก้ไข Code ส่วนตัวที่เจอประจำ Loop Query / Loop REST
3. Splitting Monolith
   - แยก DB ให้ขาด
   - แบ่ง Service ให้เหมาะตาม Domain เพื่อ Scale ได้ จัดการ Communication
   - Communication
   ->> ไม่ควร Query ข้าม Service ให้่ Service คุยกัน เช่น ผ่าน REST API มองในมุม OOP Encapsulation + Abstraction
   ->> งานเป็นแบบไหน ต้องรอ (Sync) หรือ สั่งแล้วค่อยมาตาม (Async)
   - วางแผน Monitoring (แก้ปัญหา) + Observability (เข้าใจระบบ)
   - Design for failure: จัดกลุ่มว่า Microservice อะไรที่ควรทำ HA อะไรที่ยอมตัดได้ ถ้ามีปัญหา ตอนนี้ใช้แนวคิด DDD

Warp-Up ประมาณนี้ข้าม SOA เลย

11. แบ่ง Microservice ยังไง ?

Domain-Driven Design (DDD)

• Ubiquitous Language ภาษาถื่น คำของ Business ใช้ให้ตรงกันย
• Bounded Context - หาจุดแบ่ง Boundary ออกมา
  - Core Domain Business เราขาดไม่ได้ ส่วนสำคัญของธุรกิจ
  - Supporting Domain เสริม Core
  - Generic Domain ให้คนอื่นๆ ทำก็ได้ ไม่ใช่ Core Domain

12. Microservice ของดี แต่ต้องแลกมาด้วยปัญหา (Trade Off) เช่น

Data Consistency - เรายอมลด Degree ของ DB Transaction ไปแล้ว

• Distributed Transactions มี 2 แบบ Saga / 2 Phase Commit
• Blog: สรุป SAGA Pattern จากงาน Software Architecture Meetup 2023

Maintainability - แยกเยอะ จัดการยากขึ้น ถ้าคนน้อยด้วย เป็นต้น

13. Message Queue

Messaging - ระบบอะไรก็ตามที่ใช้ส่งข้อมูล ปกติจะเป็น Message / Event ระหว่าง 2 สิ่ง System / Service / Process

• ข้อดี decoupling system + async
• ข้อเสีย จัดการไม่ดี อาจจะเป็น Single Point of Failure ได้

Messaging Component

Producer -----> Messaging System --pull/push--> Consumer

• Sender (Produder) ส่งงาน
• Messaging System - decoupling system + async + จัดลำดับ
• Receiver (Consumer) รับงาน pull/push

Message Queue = Messaging System ที่มี Buffer ทำให้ช่วยจัดการงาน Group Topic / Batch และพวก Data Safety (ต้องดูด้วยว่า ลักษณะดึงออกแล้วข้อมูลหายจาก Queue หรือยังเก็บไว้ เมื่อ Consumer รับ หรือ ทำสำเร็จ แล้วเอาออก) รวมถึง Flow Retry กรณีที่มีปัญหา จัดการกับพวก Dead Letter Qeueue โดยจะมี Component ดังนี้

• Message Queue = Queue
• Message Broker = Manage Queue

Event / Message เหมือนต่างกันไง ?

• Event - things that have already happened อะไรที่เกิดขึ้นไปแล้ว ปกติใช้ past tense เช่น order-created Maintain โดย Producer
• Message things that need to happen (Command) - Queue
  Maintain โดย Consumer

แปะไว้ exactly once approach - transactional

14. RabbitMQ

• RabbitMQ - Open Source Message Queue
  Key Feature
  - Exchange / Routing
  - Queue
  - Data Safety

ที่เคยใช้เหมือนพอคนรับ Ack ไปแล้ว มันจะเอาออกเลยนะ

15. Apache Kafka

• message (Specific Destination) vs event (รับได้จากหลายๆช่องทาง หลาย source และ State + Destination ปรับไปตามเงื่อนไข)
• Apache Kafka - Open Source Message Queue
  เน้น High Throughput / Permanent Storage / Scalable / HA
  Key Feature
  - Topic / Partitioning ถนนของ message event
  - Message Retention เข้าใจว่ารับแล้ว แต่ Topic ยังเก็บไว้จนกว่าจะครบอายุ พอเก็บไว้เลย Replay ด้วย
  - Consumer Groups - pool resource สำหรับ Scale ให้ล้อกับ Topic
  - ZooKeeper
  - KRaft/ Leader-Follower

Note Approach เคยฟังมาว่า มี 3 นะ

• Exactly Once approach - transactional
• At Least Once Approach -Consumer หยิบ Event ซ้ำกันไปทำได้ ถ้ามีน Fail แต่ไม่เหมาะกับบางเคส เช่น โอนเกินมี 3 Step ทำถึง 2 Fail วนกลับไปทำใหม่ ได้เงินเบิ๊ล
• At most once - Messages are delivered once ถ้าหายก็หายครับ

16. Cloud Native

• Cloud Native
  - Develop SW Microserverice for Agility / Resilient / Scalability / Observability with Cloud Platform
  - โดย Project / Tools / Drive by CNCF
  - CNCF Landscape แต่ละเรื่องมี Tools อะไรบ้าง
• 3P Cloud Native
  - Platform - Cloud
  - Properties - สิ่งที่อยากให้ App เช่น Loose Coupled / Resilient / Scalability / Observability / Performance เป็นต้น
  - Practices - อะไรที่ทำให้เกิด Cloud Native ได้ยั่งยื่น เช่น 12 Factor / DevOps / Container
• Note: Blog Cloud Camp ของปีที่แล้ว เผื่อลองไปอ่านเพิ่มกันครับ

17. Serverless

Serverless คือ เอา XXX ไปแปะใน ใน Platfrom ให้มันทำงานไป โดย XXX เช่น

• Code เอาไปแปะไว้ให้ทำงาน เช่น พวก Azure Function / AWS Lamda
• หรือ หลังๆจะมีพวก Database ด้วยนะ

พวก DB ผมเองเคยลองเล่นใช้ Azure Cosmos DB กับ CockroachDB ใช้ ยิงเข้าไปอย่างเดียว

• จุดเด่น รองรับงาน Event-Based / Stateless Fuction จาก Event > Auto Scale + HA
• จุดด้อย Vendor Lock มันจะผูกกับ Cloud
  Note: เหมือน K8S มีพวกนี้ Knative ยังจำที่เรียนจาก Cloud Camp ได้ 5555

นอกจากนี้กลุ่ม Serverless ยังมีชื่อเรียกอื่นๆอีก Backend as a Service (BaaS) / Function as a Service (FaaS) เป็นต้น

Serverless Challenging

• Cold Starts - เวลา Initial Instance เมื่อมี Request แรก
• Resource Limits - งานที่ทำนานๆ อาจจะไม่เหมาะ อาจจะเกิด Timeout อ่อเช้าใจและ ว่าทำไหม Cloud บางที่ออก Product ใหม่ เอา Container ไปเสียบ
• Imbalance scale - Server Less Scale แค่สวนอื่นๆ ไม่ Scale อาจจะคอขวดได้
• Hard to Debug

18. Caching

• จุดแวะพัก ไม่ให้แหล่งข้อมูลหลัก (Database / Static web) ทำงานเยอะไป โดยเอาข้อมูลที่มีการเปลี่ยนแปลงน้อย แต่ต้องตกลงกันว่า
  - นิยามว่าน้อยเท่าไหร่ (Time to Live) รายวัน รายเดือน หรือจนว่า Redeploy ใหม่ เป็นต้น
  - ถ้ามีแก้มีกลไกยังไง ลบ หรือประกาศให้ทุกคนรับรู้ ว่าต้องมาเอาใหม่
• Tools Redis / Memcached จริงๆ เอาง่ายๆ ก็ พวก Dictionary / Map ก็ได้

19. DB Chosing

ปกติแล้ว Database ที่จะคุ้นกันมี 2 กลุ่ม

- Relational Database Management System (RDBMS)

• ลักษณะเป็นตาราง (Column/ Row) มีความสัมพันธ์ primary key / foriegn key
• กว่าจะได้ตาราง Normalizae + Denormalize วนไป
• และมีคุณสมบัติ

- Atomicity - transaction is treated as a single unit ทำสำเร็จจบ ถ้าไม่ ตี Fail
- Consistency - ใน Single Unit มันต้องสอดคล้อง โอนจาก A -> B เงินหัก A ไปเพิ่ม B เก็บตาม data type / Schema
- Isolation - concurrent transactions โอนเงินพร้อมกัน มันไม่ต้องเข้ามั่ว / หลบ race condition
- Durability - อะไรที่ Commit ไปแล้วสถานะคงเดิม เช่น ปิด DB ไปเปิดมาก็เหมือนเดิม

• Scaling RDBMS
  - Scale-Up
  - Scale-Out //ส่วนตัวเคยใช่ท่านี้เหมือนกัน
  1. Sharding + Partitioning กระจาย Data ไปหลาย Node / Disk
  2. เพิ่ม Read Replicas (write 1 / read n)

นอกจาก Scale ปรับจูนบน Param + เพิ่ม Index

Sample: MySQL, MariaDB, PostgreSQL, SQL Server แถม DB2 ไป 55 ครบแล้วที่ผมเองเคยใช้

- NoSQL

มาทีหลังเหมาะกับการ Scale และ โดยมี Type เด่นๆ

• Document Store ยัด JSON ลงไปเลย
• Key Value Store นึกถึงพวก Cache Redis
• Column Family Store
• Graph DB

Note: หลังๆ RDBMS / NoSQL พยายามทำเรื่อง Scale / Distributed DB / HA กันมาขึ้น โดยหลักๆแย่งเป็น Node แต่การ replicatyion ขึ้นกับ network นะ
แต่หลายเจ้าพยายามเสนอว่า ACID + HA บ้าง เป็นต้น อาจจะเรียก Type ใหม่ NewSQL

Sample: MongoDB / Redis / Cassandra เป็นต้น

- เลือก DB อะไรดี ?

ใช้ CAP Theorem ช่วยเลือก ว่าอยากได้หมวดไหน โดย CAP มาจาก Consistency Availability, Partition tolerance ด้วยเทคโลโลยีตอนนี้ เราสามารถเลือกได้ 2 จาก 3  

• CA
• CP
• AP

นอกจากเรื่อง CAP แล้ว เราต้องมองมุมอื่นๆ เพื่อ Trade-Off ได้ เช่น

• Security (At Rest / Transist)
• Skill Team - พร้อมรับในการสร้าง และดูแลไหม หรือ ทีมต้องเรียนรู้อะไรเพิ่ม
• Operational Excellenace การดูแลหลังขึ้นจริงไปแล้ว ทำ Observability ได้ไหม เหมือนหลายๆเจ้าตอนนี้เพิ่ม End Point ออกมาให้แล้วนะเก็บ Log / Metric / Trace

แปะ What is the CAP Theorem? | IBM อ่อมีอันนี้ คล้ายๆกันแปะ สรุป DevClub#2: Databases @AWS | naiwaen@DebuggingSoft

หลังจากนี้จดจาก Coaching Session และ

21. สิ่งที่สำคัญ หรือ main key ของ Software Design

เข้าใจเรื่อง

• Trade Off - เช่น เลือก Security แล้วมันส่งผลกับ Usability เป็นต้น
• Continuous Refinement ปรับตามสถานการณ์ แต่จะกล้าปรับไปไหม ติดอะไรไหม
• ROI มันล้อกับ Trade Off

22. Software Architecture มีหลายแบบ เลือกใช้ให้ดีได้ยังไง

• Incremental Planing ปรับตามสถานการณ์
• Use Case Driven อาจจะดูจากพวก ByteGoGo ที่สรุป

23. Software Design ตอนไหนดี

• แบบแรก
  - pre-game กำหนดทิศทาง จากคนหลักๆ เช่น System Anaylsis / Solution Architect เป็นต้น
  - game ลง detail
• แบบสอง ทุกคนร่วมกำหนด แต่ต้อง Skill เท่ากัน อาจจะเหมาะกับช่วยตั้งต้นของ Product

Concept Shift Left ให้ Role ที่มาหลัก เข้ามาร้่วมกัน เช่น เอา Dev / Sec มาร่วมคุยกับ Business เลย จะได้เห็นภาพพร้อมกัน และออกแบบโดยเห็นข้อจำกัด ปัญหาได้ไว

จากข้อคุยกันแล้วอย่าลืมจดบันทึก ทำ Architecture Decision Record (ADR) รูปแบบประมาณ

• Date
• Titile
• Context - บอกว่า Why หรือ Enviroment หรือ สภาพในตอนนั้น
• Decision (What + How) - บอกทำอะไร สรุปอย่างไร ไม่มีอาจจะ
• Status - Approved / Proposed
• Consequences - ผลที่ตามมาทั้งดี และไม่มี เช่น Time เพิ่ม สอนทีม และลดงาน เพราะไปใช้ Lib เป็นต้น

ส่วนตัวผมมองว่า ADR ไม่ได้ใหม่นะ หลายๆอันอย่างพวก CMMI มันมี Practice Area DAR มาทำเรื่องนี้ CMMI บอกลอยๆ จดการตัดสินใจนะ เหมือน ADR ทำให้ชัดขึ้น เพราะมันตอบได้จริงๆ ว่าถ้าไอ้คนที่มาหลังจากเราไม่อยู่แล้ว จะได้รู้ว่าเราติดอะไร ถึงทำแบบนั้น จำได้ว่าเคยระบบ Parallel Run Site นึง คนที่มาดูแลต่อถามว่าทำไมไม่ย้ายลง Server ไป ทำไมถุึงไปอยู่ใน PC เก่าๆ ยังรู้สึกขอบคุณตัวเองเลยที่ใส่ไปว่าลูกค้าไม่มีงบประมาณ และไม่ได้จ่าย MA Solution เลยออกมาแบบนี้

ทีนี่ขึ้นกับว่าคนนั้นจะทำ หรือป่าว หรือ จะเน้น Human Document 555

24. หนังสือแนะนำสำหรับ Software Design

• Understanding Distributed System (Roberto Vitillo)
• Designing Data-Intensive Application (O'Reilly)
• Database Internals (O'Reilly)
• Fundamentals of Software Architectures (O'Reilly) - มีอันนี้อยู่ อ่านแล้ว OK เลย
• Software Architecture: The Hard Part (O'Reilly)
• Learn domain driven design (O'Reilly) - เหมือนได้จาก Humble Bundle แต่ยังไม่ได้อ่านเลย 55555 อ่าน Blog คนที่ได้เรียนพี่กับพี่รูฟ

25. Setup Go

• Download and install - The Go Programming Language เลือกตาม platform ทดสอบ Command

go version

• เปิด Code ใน VS Code หรือลองสร้างไฟล์ .go มัน Suggest อะไร เราเชื่อหมดครับ 5555 เหมือนมันจะแนะนำอันนี้ Go Extensions with Visual Studio Code

มาลองดู repo อ้าว Interface มันไม่เหมือน C# Java มันจับชื่อเหมือนกัน แล้วถือว่า Implement เลย หรือป่าว ?

ปล. แต่แอบงง เครื่องไปลง Go ตอนไหน มีแล้ว สงสัยจะตอน Cloud Camp