Clean Architecture#101 - Concept โดย ลุง bob

จากการใช้ N-tier Architecture มานาน และทำให้รู้ว่ามีปัญหามากมายในการทำ Unit Test เนื่องจากการที่โครงสร้างที่ถูกยึกติด (Dependency) มากเกินไป

ดังนั้นจุดประสงค์ที่ผมต้องเปลี่ยน Architecture เพื่อที่แยกหรือแบ่งความสัมพันธ์ออกจากกันอย่างชัดเจน
เพื่อให้ระบบเป็นอิสระ (Independent) จากทุกสิ่งเหมือนไข่ในหิน
เพราะ Bussiness มันช่างอ่อนแอ เสียนี้กระไร

อ่านไปสักพักก็พอเข้าใจโดยสังเขป
แบ่งข้อกำหนดกฎเกณฑ์เป็น 3 ส่วนใหญ่ๆ
(ตามที่ผมเข้าใจนะ อาจจะมีถูกผิดบ้าง แต้ผิดน่าจะเยอะ -_-")

---

1 - เรื่องของการเป็นชั้นการทำงาน (Layer)

ในแนวคิด (Concept) ของลุงได้แบ่งแต่ละชั้น 4 ชั้น

Entities - ชั้นในสุด แปลตรงๆก็ วัตถุ ถ้าจริงจังหน่อยก็ Data Structure , Object with method

Use Cases - ชั้นถัดออกมาเป็นส่วนที่จะเขียนส่วนดำเนินการ (Implement) ทั้งหมดในระบบ ง่ายๆก็จัดการ entity ให้ทำตาม Biz Logic ที่เรากำหนด

Interface Adapter - ถัดออกมาเป็นส่วนนี้แหละที่จะเป็นการเขียนเชื่อมกับ framework, library , db อย่างจริงจัง

External Agency - ชั้นนอกสุดเป็นก็ framework, library , db , Everything Gengerbell นั้นแหละ

        |-----------------------|         
        | |-------------------| |      
        | | |---------------| | |     
        | | | |-----------| | | |
        | | | |  Entitiy  | | | | 
        | | | |     ^     | | | |   
        | | | |-----|-----| | | |  
        | | |       |       | | |
        | | |    Use Case   | | |     
        | | |       ^       | | |  
        | | |*******|*******| | |  
        | |         |         | |          
        | | Interface Adapter | |   
        | |         ^         | |  
        | |---------|---------| |
        |           |           |
        |           |           |
        |    External Agency    |
        |                       |
><รูปปลากรอบ : The Clean Architecture : Layer>

โดยลุงบอกประมาณว่าไม่จำเป็นว่าจะ มากกว่า หรือ น้อยกว่าเสมอไป
แต่จะต้องมีกฏของการยึดติดเสมอ (Dependency Rule) คือ การพิงพาโค้ดจะต้องชี้จากข้างนอกเข้าสู่ข้างในเสมอ
ก็คือข้างนอกรู้จักข้างใน ข้างในต้องไม่รู้จักข้างนอก ประมาณนี้มั้ง

2 - เรื่องของ ข้ามพรมแดน (Crossing boundaries)

การข้ามแดนระหว่าง Interface Adapter กับ Use Case ต้องอยู่ในกฏ Dependency Rule จากที่อ่าน
ซื่งลุงแนะนำให้ใช้ - Dependency Inversion Pattern
แล้วมันยังไงละ มันอยู่ในส่วนหนึ่งของ SOLID principles อยู่ที่ตัว D นะ
ง่ายๆก็คือ ถ้าภายในจะคุยกับภายในต้องคุยผ่าน Interface ที่ภายในสร้างเพื่อติดต่อเท่านั้น

3 - เรื่องของ ข้อมูลที่ข้ามแดน (Data crosses the boundaries)

ลุงบอกว่ารูปแบบข้อมูลที่ส่งต้องเป็น โครงสร้างง่ายๆ หรือ โครงสร้างที่เกิดจากภายในเท่านั้น
ห้ามอยู่ในรูปแบบข้อมูลจากภายนอกเพราะจะผิดกฏการยึดติด (Dependency Rule)

จากการอ่านได้อะไรเยอะมากเลย พร้อมจะออกแบบ template เพื่อใช้อย่างจริงจังละ แล้วเจอกันใน part ถัดไป

Reference:
https://en.bbo.com.ph/tech/clean-architecture-and-modular-pattern/
https://stackoverflow.com/questions/49307434/clean-architecture-with-c-a-better-design-to-perform-validation-in-value-objec
https://github.com/bxcodec/go-clean-arch
https://medium.com/@thamtheera/clean-architecture-concept-423579240738
https://kritwis.medium.com/golang-clean-architecture-with-demo-e0938e5be02b
https://en.wikipedia.org/wiki/Dependency_inversion_principle
https://medium.com/@jaturapat/dependency-inversion-principle-%E0%B8%84%E0%B8%B7%E0%B8%AD%E0%B8%AD%E0%B8%B0%E0%B9%84%E0%B8%A3-7cd2c7e09b57