“半夜睡不着觉, 把心情哼成歌”
大家晚上好, 因为开发卡关却又睡不着所以上来聊聊近况并且请求建议与协助
先介绍一下我自己, 目前职称是后端工程师, 使用语言为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要知道 职责不是分得越细越好 把东西拆开了 是有代价的