看板 Soft_Job
標題
Re: [請益] 軟體開發的架構與職責
作者 brianhsu
時間 2018/07/06 18:45:34
人氣 推:0 噓:0 留言:0
熱門文章不漏接,馬上點此訂閱每日熱門文章通知
訂閱Line日報 熱門文章不漏接,馬上點此訂閱
※ 引述《DongFeng ()》之銘言: : : 目前手上的 Project 使用 Laravel Framework 開發, 程式碼架構依目錄區分為 Controller(Presentation)->Service(Business)->Repository(Data)->Entity : : 基本上各層的存取範圍以箭頭方向為準且不可逆, 但因為協同開發的關係偶爾還是會出現 Controller直接存取Repository的情況 : 有興趣可以參考 Uncle Bob 的 Clean Architecture,YouTube 上有演講錄影, 也有出書,網路上也可以找到實際的程式碼。但因為是概念性的東西,每個人的 理解和實作都有些不同。 我覺得他有一個好處,是可以跳脫 Framework 的思維,單純回歸到最原始的 OOD 的概念。這也是為什麼每個語言 / Framework 都可以實作 Clean Artitecture, 但每個人做得出來的東西又都長得不太一樣的原因。 : : : 因為沒有新的 feature/issue 的關係, 所以本週有空檔可以回頭整理之前寫的程式碼 : : 越整理我就越沮喪 : : 我發現自己沒有分辨哪些邏輯該歸類到哪一層的能力, 舉例來說: : 說真的,我自己是覺得很多時候都是 trade-off,但如果真的很在意,其實這個 架構提供了一個滿不錯的指引,但即使有這份指引,還是要考量很多東西。沒有 最好的架構,只有最適合當下情境的架構。 這篇文章我會試著以我的思路,提出一些問題,再提供一些假想的情境,然後說 明如果是我,我會怎麼安排。 Clean Architecture 把系統畫分成以下幾個組件,而且各自的職責非常清楚: 1. 與核心業務邏輯相關的,抽象的組件,這些組件不應該知道任何的實作細 節,例如資料庫,Controller 等等。 - Entity - UseCase 物件 2. 讓實作細節與核心業務邏輯溝通用的介面,通常又分兩類: - 從某處拉資料,例如 Repository 介面 - 把資料送到某處,例如 Presenter 轉換成讓 Controller 往外吐的 JSON 3. 實作上述介面的類別,也就是實作細節 : -- : 有一個 MemberService 的 Class, 負責跟會員有關的操作 : : 裡頭有一個方法 paginate 會回傳指定頁數與數量的會員資料, 除了吃指定頁數與數量的參數以外這個方法也吃另一個叫 $filter 的參數 : 視情況,在 Clean Architecture,單單是「取得分頁及過濾過後的使用者資料」這件事, 就很有可能是獨立的一個 UseCase 物件了。下面我就單以這個功能來說: 他的「行為」和「順序」是什麼? 1. 撈資料 2. 過濾資料 3. 分頁資料 接下來,我會先問幾個問題,再來確定職責所在: 1. 過濾條件也多複雜? 2. 資料量有多大? 3. 分頁這件事,會不會有其他人要用到? 撈資料不用講,一定是 Repository 的職責,因為 UseCase 不管實作細節,他 不會知道資料存在哪,是 SQL 或 NoSQL,或只是一個簡單的文字檔,他一定要 靠 Repository 才能取得資料。 過濾條件有多複雜,會影響到要把這件事排在哪做: 1. 相對應到一個簡單的 SQL 的 WHERE 指令?那我很可能選擇直接在 Repository 做。 2. 需要額外的計算,而且還要配合第三方的資料?那我會認為他應該在 UseCase 做。 資料量有多大,會影響到分頁應該是誰的職責: 1. 不大,頂多幾千到幾萬,而且其他地方也會用到分頁? 那分頁應該是獨立的 UseCase,而取得分頁過後的使用者列表,其第三個步驟, 應該只是把一二步驟取得的使用者列表丟給分頁的 UseCase,分頁這件事的職 責甚至不屬於「取得分頁過後的使用者列表」這個 UseCase 物件。 2. 資料量很大,不可能全部撈完再分頁?而且也沒有其他地方要分頁? 那這樣的情況,我會認為分頁是 Repository 的職責,讓資料庫去做這件事。 不然可能撈資料就撈到天慌地老,客戶打電話來幹譙。 : $filter 是陣列型態, 我會在方法的最開始檢查這次的 $filter 傳了哪些篩選條件進來 & 這些篩選條件有沒有符合預期的型態 : 在這裡我會想: $filter是陣列豈不是說其他要使用這個方法的人還需要知道可用的 key 有哪些? 那是不是把 $filter 拿掉改成 addNameFilter(value)->addGenderFilter(value)->paginate(page, perPage) 這樣比較好? 我倒覺得這不是問題,人家要用你的 API 本來就要懂要怎麼用,文件寫好一點就好了。 各有各的優缺點,key-value 是彈性大,method 是定義明確,看你的需要。 : : 我可以很快的完整交待的 feature/issue, 只要我能夠忍受程式碼職責切分不清 : : 但事實是我也想不出更好的寫法, 深深感受到自己的無力也對於沒有任何產能感到壓力 : 我覺得癥結點在於,你問了很多問題,但卻沒有問:「現在是什麼情境?」 配合不同的情境,同一件工作,本來就有可能需要分配給不同組件,所以在問一個職責 該分配給誰的時候,我覺得更應該問的是,「我現在面對的是什麼狀況」,不然很難有 一個好的切題的回答啊。 -- ~ 白馬帶著她一步步地回到中原。白馬已經老了,只能慢慢地走, 'v' Brian Hsu 但終是能回到中原的。江南有楊柳、桃花,有燕子、金魚…… // \\ ( 墳 墓 ) /( )\ 但這個美麗的姑娘就像古高昌國人那樣固執。 【白馬嘯西風】 ^`~'^ https://brianhsu.moe 『那都是很好很好的,可我偏不喜歡。』 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 60.251.151.199 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1530873938.A.A06.html
近期熱門文章
Soft_Job 看板熱門文章