How Does Clean Architecture Work with GoLang?

How Does Clean Architecture Work with GoLang?

การนำ Clean Architect มาใช้กับการเขียนโค้ด ช่วยให้โค้ดเรามีความยืดหยุ่นมากขึ้น ง่ายต่อการเพิ่มเข้า หรือถอดออกของแต่ละส่วน
Eknarin Thirayothin
Eknarin Thirayothin
Software Engineer

Share this?

Key Highlights:

  • Clean Architecture เป็นรูปแบบการเขียนโค้ดรูปแบบหนึ่งที่แยกการทำงานของโค้ด ตามหน้าที่ของมัน และไม่สามารถเรียกข้าม Layer ได้ ที่สำคัญคือ การเรียกใช้งานจะเป็นแบบ Outer Layer to Inner Layer
  • กรณีที่ Requirement Change ก็หมดปัญหากับการแก้ Souce Code มากมายก่ายกอง เพราะด้วยความที่ Clean Architecture แยกเป็น Layer ทำให้ถ้า database เปลี่ยน เราก็แก้แค่ 1 Layer โดยที่มันไม่ไปกระทบ กับ Layer อื่นๆ

จากที่ได้ลองศึกษาเกี่ยวกับ Clean Code Architecture จาก ลุงบ๊อบมาสักพัก เราก็เกิดอาการคันมือขึ้นมา อยากจะลองนำมาใช้กับการ Coding ซึ่งประจวบเหมาะกับเพิ่งได้มาศึกษา GoLang พอดี ก็เลยนำมาลอง Apply กันดู เลยอยากจะมาแชร์การนำ Clean Architecure มาใช้กับ GoLang ในบทความนี้ครับ

 

…เริ่มกันเลยละกัน…

 

ก่อนอื่นขออธิบายเกี่ยวกับ Clean Architect ก่อน

What’s Clean Architecture ?

Clean architect คือสถาปัตยกรรม (รูปแบบ) ในการเขียนโค้ดชนิดหนึ่ง ซึ่งเราจะแยกการทำงานของโค้ดตามหน้าที่ (Responsibilities) ของมัน

 

จากรูปด้านบนจะเห็นได้ว่า ลุงบ๊อบเขาได้แบ่ง Architecture มาเป็น 4 Layers ใหญ่ๆ 
(ปล. อันนี้เป็นทฤษฏีเนาะ ตอนเอาไปใช้จริงสามารถปรับใช้ได้ตามหน้างาน อย่ายึดติดมาก เพราะแต่ละ Techstack มันไม่ได้เหมือนกันหมด ต้องมาปรับใช้กันไป)

ทีนี้ 4 Layers มีอะไรบ้าง มาดูกัน

  • Entities: เปรียบเสมือน Data Model ของเรา ที่ไว้คอยจำแนก หรือประกาศ ว่า Data เราจะเก็บอะไรบ้าง มี Structure ยังไง
  • Use Case: เป็นส่วนที่ไว้เก็บพวก Business Logic ต่างๆ แล้วคอยเรียกใช้งาน Entity อีกที
  • Interface Adapter: ส่วนนี้ ถ้าจะให้มองง่ายๆ มันเหมือนกับเป็นตัวแปลงที่คอยเชื่อมต่อ ระหว่าง Frameworks Layer กับ Use Case layer สมมติว่าเรามีการเรียกใช้ Use Case ผ่าน Frameworks หลายๆเจ้า เจ้า Interface Adapter ก็จะคอยช่วยแปลงให้สามารถสื่อสารกับ Use Case ได้
  • Frameworks & Driver: ส่วนนี้จะเป็นพวก Request ต่างๆ รวมไปถึง External Library

 

**ตาม Concept ของ Clean Architect แล้ว เราไม่สามารถให้แต่ละ Layer เรียกข้าม Layer ไปอีกอันได้ เช่น เราไม่สามารถ เรียก Frameworks Layer ข้ามไป Use Case Layer โดยไม่ผ่าน Interface Layer เพราะมันจะทำให้ Concept ตัวนี้ผิดเพีเยนไปเลย ต้องระวังไว้นะ

**การเรียกใช้ Layer จะเป็นการเรียกจาก Outer Layer ไป Inner Layer ไม่ควรให้ Inner Layer เรียกใช้ Outer

 

ทีนี้…ลองมาดูข้อดีของการใช้ Clean Architect กัน

Why do we use Clean Architect ?

ทำไมเราถึงต้องใช้ Clean Architect ทั้งๆที่มี Architect แบบอื่นอีกมากมาย

 

สมมติว่าเรา Develop Backend services มาตัวนึง ซึ่งตอนแรกมีการ Define Techstack แบบนี้

Database: MongoDB

Language: NodeJs

Gateway: HTTP Server

โดยส่วนมาก พอเรา Define มาแบบนี้ ก็จะเริ่ม Develop เลย เขียน Config ต่างๆ 
Model ต่างๆ ให้มันเชื่อมต่อกับ MongoDB ได้ ทำ API เสร็จพร้อมส่ง

 

…แล้วถ้าหากดันมี Requirement Change ขึ้นมาว่า “ต้องการเปลี่ยนจาก MongoDB ไปใช้พวก Relational DB แทน”  ทีนี้ปัญหาก็จะเกิดขึ้นกับฝั่ง Development เพราะต้องมานั่ง แก้ Source Code เยอะแยะ จนคล้ายๆกับว่าทำใหม่

 

ซึ่ง Clean Architect สามารถเข้ามาแก้ไขปัญหาเหล่านี้ได้

 

ลองมองภาพว่า Clean Architect  มันคือการแยก Layer ออกมาตาม Responsibilities  นั่นหมายความว่าถ้าเราจะเปลี่ยน Database เราก็แก้แค่ 1 Layer โดยที่มันไม่ไปกระทบ กับ Layer อื่นๆ (จากโจทย์นี้ เราก็แก้แค่ Interfacre Adapter Layerเพื่อเชื่อมระหว่าง Frameworks Layer กับ Use Case Layer ใหม่) ซึ่งก็ค่อนข้างจะ Flexible และประหยัดเวลามากกว่ามาก

 

ซึ่งจุดๆนี้ เรามองว่าเป็นจุดแข็งของ Clean Architect  เลยทีเดียว

 

ต่อไปจะเป็นวิธีการ Apply Clean Architect  กับ GoLang ว่ามันใช้กันยังไง

How to Use ?

จาก Concept ที่เราพูดมาก่อนหน้า เราจะมาลองแบ่งในรูปแบบของ GoLang กันบ้าง โดยจะแบ่งเป็น 4 Layers เหมือนกัน

 

Domain(Entities) : เป็น Data Model หรือ Data Sturcture ที่เราจะใช้

Repository : ส่วนที่จะคอยเชื่อมต่อกับ Database ซึ่งก็จะ Apply ให้เป็นไปตามแต่ละยี่ห้อ Databse ได้ เช่น Postgres, SqlServer, MongoDB ตามแต่สะดวก หรือจะเชื่อมต่อกับ External Services อื่นๆ เช่น AWS Services ต่างๆ

Use Case : เป็นส่วนที่เก็บ Business Logic ต่างๆ

Delivery : เป็นส่วนที่จะเปิดให้ข้างนอก มาเรียกใช้ API ของเรา (HTTP Request)

 

สังเกตุได้ว่า เราทำแบบนี้ มันไม่เห็นตรงตาม Diagram ที่ลุงบ๊อบสร้ามาเลย อย่าลืมนะครับ ว่าสิ่งที่ลุงบ๊อบเขาบอก มันคือ Concept ของ Clean Architect นั่นหมายความว่า เราก็จะมา Adapt และ Apply ให้เหมาะกับหน้างาน อีกที

 

จากภาพข้างล่าง จะเป็นตัวอย่างที่เรานำ Clean Architect มา Apply กับ GoLang

The growth of interest to design systems in Russian market began somewhere in the mid-tens. The starting point is probably Anton Vinogradov’s speech at PiterCSS about the architecture of Alfa-Bank’s design system in March 2016. Although the roots, of course, should be looked for earlier.

Example Clean Architect structure with GoLang

//root

|–app

   |–module

       |–book

           |–domain

               |–book_entity.go //model

               |–book_repository.go //interface

               |–book_usecase.go //interface

           |–delivery

                   |–main.go

                   |–book_create_delivery.go

                   |–book_fetch_delivery.go

                   |–…..

           |–repository

               |–postgres

                   |–model

                       |–book_model_repository.go

                   |–main.go

                   |–book_create_repository.go

                   |–book_fetch_repository.go

                   |–…..

           |–usecase

                   |–main.go

                   |–book_create_usecase.go

                   |–book_fetch_usecase.go



จาก Folder Structure จะเห็นได้ว่า เราจะแยก Responsibilities แต่ละ Directory อย่างชัดเจน

 

Domain : เป็น Entity ที่เราจะใช้ รวมไปถึง Interface Model ต่างๆ

Repository : เป็นส่วนที่ไว้เชื่อมต่อกับ Exrternal Data Provider ต่างๆ

Use Case : ส่วนของ Business Logic

Delivery : ส่วนของ Request Handle จากภายนอก

 

พอจะเห็นภาพขึ้นไหมครับ พอเราเอา Clean Architect มา Apply ปุป Soure Code เราก็มีความ Structure ปัป ทำให้ง่ายต่อการ Plugin-Plugout แต่ละ Services

 

ทีนี้ถ้าจากโจทย์ก่อนหน้า ว่าอยากจะเปลี่ยน Database ก็แค่แก้ไขในส่วน Repositiry Directory ก็เพียงพอ

Native (iOS & Android) vs Flutter

การนำ Clean Architect มาใช้กับการเขียนโค้ด ช่วยให้โค้ดเรามีความ flexible มากขึ้น ง่ายต่อการเพิ่มเข้า หรือถอดออกของแต่ละส่วน

ทั้งนี้ Clean Architect เป็นเพียง concept ของการเขียนโค้ดหากเราจะนำมาใช้ ต้องนำมาปรับใช้งาน หรือ structure ให้เหมาะกับแต่ละภาษาที่เราจะให้อีกที

 

เรามองว่ามันไม่มีถูกไม่มีผิด 100% ว่าจะวางstructure แบบไหน แค่ให้มันตรงตาม concept ก็พอ

 

หากผู้เขียนอธิบายส่วนไหนไม่เข้าใจหรืออธิบายผิด กราบขออภัยมาล่วงหน้านะครับ

สามารถติชมกันได้

Eknarin Thirayothin
Eknarin Thirayothin
Software Engineer

Share this?

More from this Author?

Get in Touch

Get in Touch

Sign up to our newsletter

Sign up to our newsletter

Thank You for reaching out to us!

Thank You
for reaching out to us!

We’ll get back to you as soon as we can.

Thank You for signing up to our newsletter!

Thank You for signing up
to our newsletter!

We’ll serve you with amazing stories.