มารู้จักกับ Clean Architecture กันดีกว่า!

⭐️ วันนี้เราจะพาทุกคนมารู้จักกับ Clean Architecture นั้น ที่เป็น 1 article ของ Robert C. Martin หรือว่า Uncle Bob กันค่ะ!

Clean Architecture คืออะไรกันนะ?

อย่างที่บอกไปข้างบนก่อนหน้าที่เราจะมารู้จัก Clean architecture มากขึ้นใน section นี้.. Clean Architectuกre ถูกเขียนขึ้นในบทความหนึ่งของ Robert C. Martin ซึ่งเป็นผู้ที่เรียกได้ว่าเป็นผู้ที่มีอิทธิพลในเรื่องของการเขียนโค้ดที่ดี หรือที่เค้าเรียกว่าเขียนโค้ดให้ clean นั่นเอง บทความนี้ชื่อว่า "The Clean Architecture" ถูก publish มาตั้งแต่ปี 2012 (เกือบจะ 10 ปีแล้ว)
.
จุดประสงค์ของการใช้ Clean Architecture จะช่วยให้เราสามารถแยก layer ของโค้ด โดยในแต่ละ layer ก็จะทำงานของตัวเองอย่างชัดเจนไปเลย หรือที่เราเรียกว่า separation of concern นั่นเอง

ทำไมเราถึงมาใช้ Clean Architecture ล่ะ?

อย่างแรก คือ "Independent of Frameworks" หมายความว่า โค้ดที่เราเขียนจะไม่ผูกติดอยู่กับ framework ไปทุกส่วนของโค้ด ในวันไหนที่เราอยากจะเปลี่ยนไปใช้ framework อื่นๆ จะได้ปรับเปลี่ยนได้อย่างง่ายขึ้น
.
อย่างที่สอง ได้แก่ "Testable" หมายถึง เราจะสามารถ test code ของเราง่ายขึ้น ตัวอย่างเพื่อให้เห็นภาพมากขึ้น คือ การแยกส่วนของ business logic ออกจากส่วนอื่นๆ เช่น UI หรือ database เวลาที่เราเขียน test ส่วนของ business logic ก็จะง่ายขึ้น เพราะไม่ต้องสนใจเรื่อง UI ว่าจะต้อง render อย่างไร หรือว่าจะต้องไปต่อกับ database ตัวไหน เป็นต้น
.
อย่างที่สาม คือ "Independent of UI" เมื่อเราแยกส่วนของ UI ออกจาก business logic แล้ว สิ่งที่ง่ายขึ้นก็คือ เราสามารถเปลี่ยนแปลง UI ได้โดยไม่ต้องกังวลว่า business logic จะพังทลายไปด้วยหรือเปล่า
.
อย่างที่สี่ คือ "Independent of Database" เป็นการแยกส่วนที่ติดต่อกับ database ออกมา สมมติเหตุการณ์สักหน่อย ก็คงจะนึกถึง case ของ เวลาเราสร้าง project ขึ้นมาใหม่ เราใช้ database sqlite แต่นานวันเข้า sqlite ไม่ตอบโจทย์ของการใช้งานของ user จริงๆ บน production เราจะต้องเปลี่ยน database ไปใช้ Oracle แทน เราก็สามารถทำได้ง่าย เพราะเราได้แยก layer ไว้อยู่ที่ layer เดียวแล้ว
.
อย่างสุดท้าย คือ "Independent of any external agency" หมายถึง business logic ต่างๆ จะไม่รู้ว่าเกิดอะไรขึ้นภายในโค้ดที่ business logic สนใจเลยยย
.
โดยเหตุผลเหล่านี้ ก็ถูกเขียนอยู่ในบทความ The Clean Architecture ด้วยเช่นกัน ใครอยากอ่าน version ต้นฉบับ ก็สามารถเข้าไปตามอ่านกันได้ ที่นี่ เลยจ้า

The Dependency Rule ของ Clean Architecture

จากภาพข้างบน เราจะเห็นได้ว่า แต่ละวงกลมจะสื่อถึง layer ต่างๆ เวลาที่เราทำ software ใดๆ ก็ตาม โดยวงกลมที่อยู่ด้านนอกๆ จะสื่อถึง layer ที่สูงๆ ซึ่งโดยทั่วไปก็จะเป็นส่วนที่ติดต่อกับคนที่ใช้งาน ส่วนวงกลมที่อยู่ด้านในๆ ก็จะเป็นส่วนที่ low level มากๆ อย่างเช่น ส่วนที่ติดต่อกับ database เป็นต้น
.
เรามาทำความรู้จักมากขึ้นกับวงกลมแต่ละ layer ให้มากขึ้นกันดีกว่า 🎉

Entities

ส่วนนี้เป็นส่วนที่ติดต่อกับ Enterprise Business Rules ซึ่งโค้ดที่เกิดขึ้นใน layer นี้ อาจจะเป็น model ที่เก็บ data structure ของข้อมูลในองค์กรของเราก็ได้ โดยส่วนนี้จะมีการเปลี่ยนแปลง และกระทบน้อยที่สุด เนื่องจากเป็นชั้นด้านในที่สุดเลย เช่น ถ้าหากเราเปลี่ยนแปลง UI จาก design แบบหนึ่ง ไปเป็นอีกแบบหนึ่ง ก็จะมีโอกาสน้อยมากที่ structure ของ data ของเราจะเปลี่ยนแปลงไปตาม

Use Cases

ส่วนนี้จะเป็นส่วนที่มี Application Business Rules อยู่ ซึ่งโค้ดใน use case เหล่านี้ก็จะเป็นส่วนที่ควบคุมว่าจะมี data อะไรที่จะนำออกจาก.. หรือนำเข้าไป entities บ้าง โดยที่จะทำให้ได้ผลลัพธ์อย่างที่โปรแกรมของเราต้องการ

Interface Adapters

ส่วนนี้จะประกอบไปด้วยส่วนที่เอาไว้ใช้ convert data จาก format ใดๆ ก็ตาม ให้เป็น format ที่ application ของเราเข้าใจและใช้ได้ง่าย เช่นการแปลงจาก json format ให้เป็น object ที่เราต้องการ เราจะเรียกสิ่งที่ทำหน้าที่เหล่านี้ว่า Adapter ซึ่ง Adapter ถ้าแปลเป็นไทยก็คือ "ตัวแปลง" นั่นเอง

Frameworks and Drivers

เป็นส่วนที่จัดการกับ framework ที่เราใช้ในโปรเจกต์ ในส่วนนี้เราอาจจะไม่ได้เขียนโค้ดมาก แต่ก็เป็นส่วนที่สำคัญ เพราะเราเอาไว้ใช้ ติดต่อกับ framework ต่างๆ ที่เราใช้ เช่น การเขียนโค้ดเพื่อสร้าง database connection เป็นต้น
.

และนี่ก็คือ..​. แทบจะเป็นทฤษฎีของ The Clean Architect ที่เราลองเขียนสรุปตามความเข้าใจของเรามาให้ทุกคนได้ลองรู้จักกับสิ่งนี้ เพื่อให้การเขียนโค้ดของเราดีขึ้นนะคะ และจริงๆ แล้ว ถ้าจะเล่าให้ฟังให้เห็นภาพมากขึ้น เราน่าจะต้องทำความเข้าใจในการ apply ด้วยว่าถ้าจะเอา Clean Architecture ไปใช้งานจริงๆ แล้วเราจะทำยังไงกันนะ...
.
ซึ่งเราขอ spoil ตอนต่อไปเลยละกันว่า..​ เราจะพาทุกคนไปทำความคุ้นเคยมากขึ้น ว่าถ้าเกิดเอาไปใช้กับโปรเจกต์ที่เขียนด้วย golang ล่ะ มันทำยังไงกัน! เพราะฉะนั้นติดตามตอนต่อไปได้เลยจ้าาาา 😎

Reference

• https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

Comments

[สาธุชน ณุ]

ถ้า Business Login มันต้องเชื่อม database ตลอด จะแยก Test ยังไงดีครับ

[Chakrit Likitkhajorn]

Assume ว่ามันทำงานถูกครับแล้ว Mock ของแทน

เช่น

class CustomerRepository
{
   public double CalculateNumberOfActiveCustomer() {
    // complicated logic here
   }
}

ถ้ามันขึ้นอยู่กับ Stored Procedure ในฐานข้อมูล เราก็เทสโดย Mock class นี้มาแล้วก็บอกว่า App เราทำถูกแล้วแต่ฐานข้อมูลมันทำงานผิด อย่างน้อยก็ระบุได้ว่าส่วนไหนเป็นปัญหาครับ

[สาธุชน ณุ]

ขอบคุณครับ 😊
เดี๋ยวเอาไปปรับใช้ดูครับ

[arima]

ถ้าเป็นเคสที่เราต้องแชร์ Business logic กัน(เพราะเราไม่อยากให้เกิด Duplicated code) เราจะทำยังไงครับ?

[Anuwong Mongkudkornburee]

ยอมให้ duplicate ดีกว่าสร้าง dependency ครับ ถ้า duplicate นั้นไม่ได้ทำให้ velocity ในการพัฒนาเสียไป และต้องเขียน Unit Test คุมไว้เสมอครับ