Clean Architecture#101 - Concept โดย ลุง bob 
Published: 2021-07-09 15:57:19

### จากการใช้ 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](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)
แล้วมันยังไงละ มันอยู่ในส่วนหนึ่งของ 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