寫在前面：在研究一個新東西的時候，我習慣于拿手頭的項目去做類比，所以即使這些原則更多的是在描述面向?qū)ο螅以诶斫獾臅r候也是在往嵌入式C實時系統(tǒng)去靠的。
先列上三個原則：
1. REP復用/發(fā)布等同原則：軟件復用的最小粒度應等同于其發(fā)布的最小粒度。
2. CCP共同閉包原則：我們應該將那些會同時修改，并且為相同目的而修改的類放到同一個組件中，而將不會同時修改，并且不會為了相同目的而修改的那些類放到不同的組件中。
3. CRP共同復用原則：不要強迫一個組件的用戶依賴他們不需要的東西。
作為一個架構(gòu)菜鳥，這里面有很多概念是模糊的。
首先，什么是復用。百度百科這么描述：“將已有的軟件成分用于構(gòu)造新的軟件系統(tǒng)”，通俗講，我覺得是這個迭代發(fā)布的成分功能，未來仍然在這個成分的基礎上修改之后發(fā)布新的功能。
那么REP原則在主張什么。從代碼角度，完全的REP原則會導致軟件變大。比如特性跨組件是很常見的，按照REP原則，這些跨組件的功能應該屬于一個組件。我覺得REP原則在組件設計中的作用非常虛，簡單來說就是功能內(nèi)聚。換個角度看REP，他提出了一系列非組件設計的要求：能容易地添加新的功能擴展，組件內(nèi)的模塊遵循統(tǒng)一的發(fā)布版本。
REP原則我覺得放在軟件項目管理里非常合適。DDD強調(diào)劃分特性團隊，特性終結(jié)在團隊，粗暴的特性團隊劃分又會導致架構(gòu)守護困難，此時通過劃分領域的方式將交付節(jié)奏或波及頻率相同的組件劃分到同一個領域能解決架構(gòu)守護的問題。
共同閉包原則是組件級的單一職責原則。我一直覺得單一職責原則是水很深的原則。脫離業(yè)務，你很難說清什么叫單一職責。單一職責函數(shù)的命名實際上定義了文件或函數(shù)之間的統(tǒng)一概念和層次結(jié)構(gòu)。變更頻率相同的塊放在同一個組件，變更頻率相同從側(cè)面描述了“相同目的”，這是REP更進一步的描述。CCP原則和開閉原則的關聯(lián)有點略顯牽強，其實還是在說統(tǒng)一變更頻率。
共同復用原則建議將經(jīng)常共同復用的類和模塊放在同一個組件中?！爱斘覀儧Q定要依賴某個組件時，最好是實際需要依賴該組件中的每個類”，這條建議可以說非常具體了，它實際告訴我們哪些功能塊不能被放在一起。
三個原則關系見下圖:
三個圓圈把三個原則的本質(zhì)目的講得很清楚。不關注CCP會導致組件劃分太多太細，即使簡單功能也會波及很多組件；不關注CRP會導致大組件，很多小功能頻繁發(fā)布。文中說，隨著項目逐漸成熟，項目重心會左移，CCP移向CRP好理解：為了追求開發(fā)速度，組件功能小而單一，大組件維護方便，隨著功能越來越多，就會進行組件拆分。向REP移動不是很好理解，主要是這里的復用性：怎樣的組件劃分能對新增需求更加親和。待我再找找資料再來回答吧。
