把六個資料夾塞進一個模組裡：小團隊的程式碼架構如何踢破潔癖濾鏡

兩三個人組成的開發團隊，打開剛建立好的 Android 專案 workspace。為了追求所謂的架構整潔，他們決定把程式碼拆分成登入、首頁、個人中心、核心網路等六個以上的獨立模組。幾個月後，開發者發現自己花在調整 Gradle 設定與處理跨模組依賴報錯的時間，遠遠超過撰寫實際業務邏輯的時間。

2026 年 8 月，一篇發布於技術社羣掘金的文章，精準踩中了這個讓許多年輕開發者隱隱作痛的現象。這篇由開發者發布的實戰經驗分享，標題直言不諱地點出了小團隊的最優解：單一模組搭配包內分層架構。

在這篇被社羣廣泛轉發與討論的文章中，作者戳破了許多軟體工程師對於完美架構的過度想像。它反映出的現象，其實是科技業中一種典型的「架構濾鏡」。開發者往往為了讓專案看起來具備大型互聯網公司的規模感，提早將複雜度引入了還在生存線上掙扎的小型專案。這與我們先前觀察過的那張撕不開的電信資費帳單有著相似的心理機制，現代人總是習慣性地把簡單的日常需求，包裹進一套極度複雜的系統裡。

架構濾鏡的誕生與代價

當一個軟體工程師在面試時展示自己的 side project，或者試圖將一個三人初創團隊的應用程式包裝給投資人看時，一個具備多重模組的專案結構，往往能傳遞出某種工程嚴謹度。這就是架構濾鏡的來源。

技術論壇裡充斥著對各種架構名詞的討論。講到 Clean Architecture（整潔架構），很多開發者的第一反應是必須要把專案拆解成無數個模組。於是，一個原本只需要幾週就能跑通邏輯的小型應用，被硬生生拆分成了五到六個甚至更多的模組。開發者很快就會面臨幾個具體的麻煩：

• 修改一個基礎功能，需要在多個模組之間反覆跳轉。
• Gradle 建置工具的設定檔變得異常龐大且脆弱。
• 除錯鏈路拉長，追蹤一個變數的傳遞過程變得極度耗費心力。
• 真正留給開發核心業務邏輯的時間被大幅壓縮。

這種為了解決未來可能發生的問題，而提前把複雜度建立起來的行為，在技術社羣裡被稱為過度工程。對於一個只有兩三個人的 Android 團隊來說，使用多重模組主要解決的是編譯隔離、團隊協作邊界以及依賴隔離等大型工程治理問題。然而，當團隊規模極小時，每個人對整個專案的底層邏輯都相對熟悉，協作衝突的概率非常低。

在這種情況下，強制使用模組來畫分邊界，帶來的收益遠不及增加的管理成本。這就像是一個只有三個人的新創辦公室，卻硬要導入跨國企業的層層簽核流程，最後只會讓所有人都在填表單，沒有人在做實事。

Clean Architecture 的核心誤區

拆分模組之所以在開發者社羣中蔚為風潮，很大一部分原因是對 Clean Architecture 這個概念的誤解。

這套由軟體工程師 Robert C. Martin 提出的經典軟體設計哲學，其真正解決的問題是依賴和職責的分配，而不是模組數量。它的核心目標非常明確：控制程式碼的依賴方向，讓核心業務規則不要被具體的技術實現綁架。

當一個開發者遵循這套哲學時，他需要關注的是誰依賴誰、業務邏輯應該放置在哪一層、資料庫存取的細節應該藏在哪裡，以及當外部資料源發生變化時，核心的商業邏輯是否需要跟著修改。這些問題的答案，完全可以透過良好的程式碼目錄結構來達成，而不需要動用到工程層面的模組隔離。

模組只是一種實現隔離的工程手段。開發者完全可以採用單一模組，搭配上清晰的包內邊界，同樣做到職責清晰與依賴方向正確。把 Clean Architecture 直接與多重模組劃上等號，是許多剛接觸進階架構設計的工程師最容易踏入的認知陷阱。

走回單一模組的減法哲學

既然不拆分模組，那麼要如何保證程式碼不會隨著開發進度變成一團亂麻？該名開發者在文章中給出的解答，是回歸最原始的資料夾管理：用功能特性作為業務聚合的單位，用套件名稱來執行架構隔離。

在一個名為 CleanArc 的實戰專案展示中，開發者拋棄了那種一上來就把整個專案拆成表現層模組、領域層模組和資料層模組的傳統做法。取而代之的，是將整個應用程式保留在同一個模組下。首先，目錄被劃分為共用核心與功能區塊。在每一個特定的功能（例如登入功能）之下，才會進一步進行 Clean Architecture 的三層切分。

這套目錄結構的核心思想非常直觀。它將原本橫向的架構分層，轉變為縱向的功能導向。每一個功能模組內部，都包含了 presentation（表現層，負責 UI 與狀態管理）、domain（領域層，負責商業邏輯與資料模型）以及 data（資料層，負責具體的資料庫與網路請求實作）。

當開發者需要修改登入功能時，他只需要在單一的 feature/login 資料夾內完成所有工作。跨層的依賴方向依然嚴格遵守著 Clean Architecture 的規則，表現層依賴領域層，資料層實作領域層的介面。差別僅在於，這一切都發生在同一個編譯單位內，省去了所有因為模組拆分而產生的溝通成本。這就像我們曾探討過的微軟將 Windows 圖片密碼功能除役一樣，有時候讓工具回歸純粹與簡單，反而能帶來更流暢的使用體驗。

從程式碼結構看見的工作哲學

這場關於 Android 專案架構的技術討論，雖然充滿了 Gradle 與 ViewModel 等硬核工程詞彙，但它背後折射出的其實是一種當代的工作與管理哲學。

在各個行業中，我們都能看到類似的情境。小型團隊在初創時期，為了展現出某種專業感與未來擴充性，往往會過早引入大企業的標準化作業流程。軟體工程師為了兩三個人維護的應用程式建立起複雜的微服務架構；幾個人的工作室訂定了繁瑣的跨部門績效考核流程；甚至在我們的日常生活中，人們也習慣用各種生產力工具把自己的待辦事項拆分成無數個細碎的看板。

拆分與模組化本身並沒有錯，它們是應對複雜度的利器。但當複雜度還沒有真正降臨時，這些工具反而成了拖累效率的元兇。技術論壇上對於單一模組架構的重新推崇，某種程度上是開發者社羣對過度工程化的一次集體反思。人們開始意識到，解決問題的優雅程度，往往取決於你能否在正確的時機點忍住不增加複雜度。

下次當你面對一個全新的專案，無論是一支應用程式，還是生活中的某個新計畫時，在把結構切分得支離破碎之前，或許可以先問自己一個問題：我們是真的需要這些邊界來隔離風險，還是只是為了讓自己看起來更像一個龐大而成熟的組織？