「半夜睡不著覺, 把心情哼成歌」
大家晚上好, 因為開發卡關卻又睡不著所以上來聊聊近況並且請求建議與協助
先介紹一下我自己, 目前職稱是後端工程師, 使用語言為php, 相關年資累計約五年四個月
目前手上的 Project 使用 Laravel Framework 開發, 程式碼架構依目錄區分為 Controller(Presentation)->Service(Business)->Repository(Data)->Entity
基本上各層的存取範圍以箭頭方向為準且不可逆, 但因為協同開發的關係偶爾還是會出現 Controller直接存取Repository的情況
因為沒有新的 feature/issue 的關係, 所以本週有空檔可以回頭整理之前寫的程式碼
越整理我就越沮喪
我發現自己沒有分辨哪些邏輯該歸類到哪一層的能力, 舉例來說:

這個直接電死

找 refactor 相關的書籍？

Bob大叔是精神支柱

建議可看看Domain driven design的書，對於各層職責會有不同的想法

按照基本思維，Service是功能，Filter自然是在Service，key不是問題，想用你的filter的人自然本來就需要了解你的filter使用方式，不然就寫個enum用autocomplete來選key。

同樓上，不然就學JAVA流吧，一堆o，定義的清清楚楚

先提醒 小心走火入魔 XD基本上要把握一個大原則 「不要為了設計而設計」要為了「改變」而去做設計 也就是說 當你困惑該怎麼分職責或要使用哪一個架構時 先使用最簡單 最方便 最直覺的方式解功能做出來測試也做好之後 想一想 這個部份是否「很常改變」 如果幾乎不會改變 或是依照目前情況看下來 應該是不太會有變動 那就可以放著了 如果你不確定這部份是不會之後會修改到 你可以和其它工程師和需求方討論看看 甚至做個小投票如果一開始就知道這部份常常會因為需求變化而要做更動 那就得思考更靈活 但卻更複雜的架構了 這時再來重構它回到你提的案例 真正要問的問題 是你的filter未來半年到一年內是否會因為需求而要作修改 如果看起來不太會 那就用最初的驗證寫好就好了 別再自尋煩惱職責切分不清不是大問題 真正的問題是出在 你在沒有必要的地方 也做了SOLID和設計模式 造成overdesign要知道 職責不是分得越細越好 把東西拆開了 是有代價的