Facebook加入
LINE加入
2021/12/25
什麼是Clean Architecture
The Clean Architecture是《Clean Code》作者Uncle Bob提出的一種架構。
開發高質量的軟體一直是複雜而又困難的。因為高質量的軟體設計不僅僅要滿足當下的需求，更需要強壯、易於測試、強延展性。
The Clean Architecture正是一個滿足高質量軟體設計的架構。其主旨為
• 框架的獨立
• 易於測試
• UI的獨立
• 數據源的獨立
• 業務的獨立
這篇文章關於The Clean Architecture的介紹到此，具體內容可以自行查詢。
我的實踐
我為什麼應用實踐The Clean Architecture
1. 因為我看到關於Clean Architecture的文章的時候項目青黃不接，我想搞事情。
2. 我被它能幹的事兒吸引
3. 我所經歷的Android程序設計混亂得令我感到絕望（後來我稱採用架構之前的Android開發為黑暗時代）
4. 當時並沒有真正理解到它的核心，但我是一個先做起來的人
我怎麼把The Clean Architecture這個普適的思想用在Android開發上
在進行開發時我主要參考了
• 文章Architecting Android...The clean way?
• 項目Android-CleanArchitecture
核心使用到的工具包含
• Retrofit
• RxJava
• Dagger
如上圖，整個項目最終分為了6個Module：
• cleanarchitecture:這個Module是一個Java Library。包含實現The Clean Architecture的基本類，如Executer抽象，Presenter抽象等。
• domain:這個Module是Java Library。包含了核心業務的抽象。
• data:這個Module是Android Library。包含了核心業務相關的實現。
• framework:這個Module是Android Library。是上拉更多下拉刷新、JSON等通用組件的抽象實現。
• customer:這個Module是Android App。是這個項目的其中一個APP
• merchant:這個Module是Android App。是這個項目的另一個APP
結果怎麼樣
我可以負責任的說：「效果拔群」。從幾個方面來說：
1. 業務抽象。公司的核心業務完全抽象到了Domain。各個App基於核心業務進行應用業務的演繹。
2. 結構層次清晰。整體的結構非常清晰。上帝的歸上帝，凱撒的歸凱撒。
3. 抽象與實現分離。data與domain分離，想用file用file，想用cloud用cloud，想用db用db
我獲得了什麼
經過刺激又新奇的實踐。這個架構帶來了上文提到的三個好結果。其中第一個「業務抽象」讓我想到了一些不同的東西。
關注點
從前
從前開發關注點放在當前sprint的需求、業務上。很多開發者只知道當前要做的，頂多了解未來也許要做什麼，這個需求也許來自於客戶，也許來自於產品經理。那麼對於這些開發者來說，特別關注當前的需求、當前的業務無可厚非。
現在
我的關注點產生了轉變。我的關注點不再是當前需求，當前業務，甚至不再是項目的需求項目的業務。而是核心領域。
什麼是公司的核心領域？例如對於淘寶網來說，淘寶賣的是商品；淘寶買的也是商品；天貓賣的是商品；天貓買的也是商品；閑魚賣的也是商品；閑魚買的也是商品；商品是包含於核心領域。同樣的，訂單也是，用戶也是。
若在設計系統時，把公司核心領域抽象到系統內。各個業務系統（app）只需要在需求到來時各自演繹。還是以淘寶為例，無論是買家還是賣家，無論天貓、淘寶還是閑魚，商品就是核心領域的商品，只是在各個業務系統進行不同的展示和操作。這裡說道操作，操作也是包含於核心領域的，如「買家取消訂單」操作。
我們的關注點從某個業務系統（app）的內容，轉移到了公司的業務。這樣，我們掌握了公司到底擁有什麼，到底會產出什麼。只要不改動公司的核心領域，無論產品經理如何演繹，無論如何用戶要求多查看一些什麼，都在我們的掌控範圍之內。
項目積累
成功的政治家必定需要積累政治資本，成功的銷售人員必定需要積累客戶，在公司供職的開發者當然也需要有所積累。一個項目除了做業務外也需要有積累。
之前我的迷思
有很長一段時間我們嘗試抽象各種widget，json什麼的，做一套我當時叫做「Android基礎設施」的東西，作為公司所有Android項目的基石。後來我們放棄了，隨著新的ui設計思想的誕生，新的Android SDK的發布，一切都變得困難而無意義，甚至怨聲載道。
我不知道可以積累什麼才能具有核心競爭力。
積累核心領域
我們可以積累核心領域。
我們應該不斷的積累核心領域，不斷的更新同步核心領域。以我對於後端開發有限的了解，他們就是在不斷的做這件事，甚至是定義核心領域，那麼移動端為什麼不能做這個積累呢？為什麼移動端一定要被後端牽著鼻子走呢？。
• 如果我們面向核心領域編程（我們姑且把積累公司核心領域叫做面向核心領域編程），那麼後端如何實現，對移動端來說不再起決定作用，只是在於移動開發演繹時如何把後端實現的領域接入移動端抽象的領域，因為後端也無法走出領域的範圍。
• 如果我們面向核心領域編程，我們可以預見需求，在需求實際提出之前就做好準備。
• 如果我們面向核心領域編程，我們可以獨立的對核心領域進行高強度測試。
• 如果我們面向核心領域編程，我們可以快速的開發出新的業務系統（就算是開發個鹹蛋也逃不出這個核心領域）
個人要求的改變
為了實現這個積累，對於移動端開發者有了新的（我認為一直存在）的要求
1. 充分了解公司背景與所涉
2. 充分了解核心領域的範圍
3. 要想做測試覆蓋一樣去覆蓋核心領域的各個分支
4. 把目光放的比以往任何時候都要遠與廣
開發流程的改變
為了實現這個積累，開發流程也應該有改變
1. 應該自內而外的開發。先定義核心領域，再在其上進行演繹。
2. 核心領域不應該依賴於業務系統的任何部分，其至於公司實際業務有關。
3. 應該對於核心領域進行高強度的測試。
4. UI開發，工具開發等等都應該服務於核心領域。甚至基於核心領域有預見行的進行UI開發。
我不是一個人
我發現這樣想的人並不只有我。也許這樣的想法是每個真正理解The Clean Architecture的人都可能會認同的。甚至有人認為這個就是Domain Driven Design。提供一個視頻，這是一個項目lead關於Domain Driven Design在Android開發中的例子，他使用的也是The Clean Architecture，內容比較詳細，包含了很多細節。
感謝
感謝我這篇文章提到的所有「巨人」，讓我脫離了黑暗時代。
感謝能耐心看到這個地方的人。畢竟這篇文章幾乎都是字，沒有圖，也沒有『Show you code』。內容也只是個人的感想，對於大部分人來說枯燥無味。
reference:
[The Clean Architecture]:https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html
[Architecting Android...The clean way?]:https://fernandocejas.com/2014/09/03/architecting-android-the-clean-way/
[Android-CleanArchitecture]:https://github.com/android10/Android-CleanArchitecture
[Domain Driven Design]:https://en.wikipedia.org/wiki/Domain-driven_design
[提供一個視頻]: https://www.youtube.com/watch?v=uwJRrJ2Hwqg
本文作者：本文作者：徐珺煒（點融黑幫），成都分公司開發者，負責Android應用開發。是Clean Architecture機構實踐者，全棧玩家，最近喜歡看史，已經胖得無法運動了。
熱門推薦
留言回覆
