OOP ช่วยจัดระเบียบโค้ดแต่ยังไม่พอ ลองคิดดูว่ามีเป็นหมื่น class
เราเลยต้องจัดกลุ่ม class
One software architect's works are about
“a way to make a sense out of system”
คำถามคือจะจัดกลุ่มยังไง?
- มีเหตุผล
- มีความ make sense → make sense สำหรับใครบ้าง?
- เข้าใจง่าย หาของเจอได้ง่าย
แต่ว่าการจักกลุ่มจริงๆแล้วมันต้องดูที่ Domain รึปร่าว?
คำตอบคือ ใช่!
N-Tier architecture vs Domain
การจัดกลุ่มตาม Layer
design pattern แต่ละตัวดีอย่างไรต้องดูด้วยว่าเทียบกับอะไร เช่น
ข้อดีของ N-tier ที่เขาเครมกันแต่เทียบกับ God class แต่เมื่อเทียบกับ Domain architect แล้วก็ไม่ดีกว่า
เวลาเลือกใช้ architec ต้องดูบริบทและ enviruement ด้วยเป็นสิ่งสำคัญสุดๆ
MVC — แปลง input, output ให้เป็นรูปที่เข้าใจได้
- controller handle input-output
- View tell how to display
- Model is the business and internal logic
แต่เขาบอกว่า Model จัดการเรื่อง database? มีบางอย่างที่เราเข้าใจผิดอยู่
ส่วนใหญ่ใน standalone MVP web application ระบบภายในคือ Database
แต่ระบบอื่นไม่ใช่ Model คือระบบภายนอก
MVC มัน fit together ช่วยให้ specialist ทำงานร่วมกันได้
Clean Architect — code base เป็นอิสระจาก third-party
ในยุคนั้น big enterprise มันมี legacy systems หลายตัวมากๆ เลยเกิดไอเดียนี้มา
ทำยังไงถึงจะแยกโค้ดที่เราเขียนกับส่วนที่ realize third-party
หัวใจสำคัญคือ Entities ไม่ขึ้นอยู่กับ third-party
clear architecture เน้นย้ำ Domain knowledge ถึงจะทำงานกับมันได้เพราะสิ่งที่สร้างจะส่งผลต่อ entities, UseCase เสมอ
นักพัฒนารู้แค่ codebase ไม่ต้องรู้ ingration ว่าทำงานยังไงก็สามารถพัฒนาได้จุดนี้เป็นทั้งข้อดีและข้อเสีย
สิ่งที่สำคัญว่า third-party ก็คือ Skill Matrix
การแบ่ง tier ดีจะช่วยให้เราจัดการทีมได้ดีขึ้น
เมื่อไหร่ควรใช้ Clean ?
Complex-lar system → ใช้ Domain knowledge ที่หลากหลายแล้วใช้ clean มาจัดการมัน
Business Collaboration
เวลาทำงานกับ Bussiness จะไปใช้ word ที่แตกต่างออกไปเราต้องแปลงเป็นภาษาโค้ดอีกทีทำให้เป็นปัญหาในการทำงานทุกวันนี้
ถ้าโค้ดที่เราเขียน term มันเหมือนกัน Domain Business ก็คงจะดี
Domain-Driven Design → เทคนิคการ design ตาม business model
ช่วยทำให้เห็นภาพเดียวกัน
DDD มี detail การทำเยอะเดียวค่อยมาจดต่อ
