我自己心中的理想是controller把service class的business logic回傳object轉成response object / catch exception 轉成 response status

joshua5201: 目前有聊過的人，實踐 Clean Architecture 最後都會是這個形狀 XD

忘記是看到底幾次時才發現 Clean Architecture 把 Controller 標記成 Adapter 所以定義上確實是做 Input/Output 的轉換最接近

後面我覺得比較難的就是 Service Object 到底該看作一種 Use Case 會在 Controller 呼叫 N 個，還是看作是另一種物件，由 Use Case 統一調度

我個人目前是偏好後者，這樣在做不同協定時比較好處理，如：gRPC 要加進來時，呼叫 Use Case 就好，不用再搬一次 Controller 的內容

不過這也會有另一個問題，如果要組 Input/Output 會一大包，對 Use Case 來說有點麻煩

對啊 其實我沒有讀過clean architecture
但我知道 通常很複雜的邏輯 第一層service class比較像是乾淨的entry point，他的input/output/exception不必跟實際的protocol有關連
它還是會有很多dependency 最

有些爛code就是覺得我沒有寫在controller就乾淨了 但service class幾千行XD

我也不喜歡在controller call好幾個service method這樣就有點把business logic混進去

Service Object 幾千行有點看語言，之前寫 Ruby 的時候大多可以控制在 100 行左右，我在 Golang 要做類似的事情就得多很多 if 去檢查，塞一塞可能會到 150 ~ 200 之類的

另一方面是目前在慢慢抓 Domain-Driven Design 的形狀，現在反而是比較擔心拆太細在初期有點過度 XD

我自己讀過 Clean Architecture、Design Pattern 這些之後，都覺得基本上就是經驗總結，寫程式有在動腦大部分都能抓到類似的方向，讀過就是少走歪路

如果寫程式沒在思考，讀了寫出來還是一樣糟，可能還會因為硬要照某些實踐搞出更恐怖的東西