大多數的開發人員在講dry (don't repeat yourself) 的時候大多認為dry是功能和**的重複，也就是oaoo (once and only once)，其實不盡然。物件導向設計提倡的oaoo，強調的是利用物件導向的繼承、組合等特性盡量讓乙個功能點只存在乙個地方，所以oaoo強調的是物件導向設計，以及功能**方面。而dyr的範圍比oaoo要廣泛得多。dyr更多的是一種架構設計思想，在軟體開發過程中的萬事萬物均可能重複，大到標準、框架、開發流程；中到元件、介面；小到功能、**均純存在自我重複。而dyr提倡的就是在軟體開發過程中應消除所有這些自我重複。在軟體過程中的自我重複，總的來說有五種型別：
(1) 一件事物，有多種的不同語言和方式來表達，不同的角色採用不同的語言去描述同一事物。在這些角色之間需要協同工作時造成的重複。
比如，架構設計師用一種語言和方式描述其架構設計，可為ppt、word文件、visio、建模工具等。開發人員的工作語言則是程式**。兩種角色描述的是同一事物，只是描述語言不同而已，這樣造成架構設計師的架構輸出，不能作為開發人員的開發輸入，而不能被開發人員重用，導致一定的自我重複。這就像乙個人用英文寫書，乙個人用中文寫書，內容類似，那麼中文作者要麼重新整理內容並書寫書籍，要麼就翻譯英文書籍，不管哪種，造成重複工作勞動是在所難免。
對於此類的自我重複，隨著模型驅動的成熟和廣泛應用將逐漸減少。模型驅動架構中業務建模、架構建模和程式編碼等之間，通過unified modeling language(uml)、the meta-object facility (mof)、xml metadata interchange (xmi)和自動化**生成等語言、標準和技術進行互相轉換，達到don't repeat yourself。如下圖所示：
傳統的開發過程中，需求、分析、設計、開發等各個階段，可能採用不同的描述語言和方式，互相之間也較難轉換，所以他們之間不能無縫的相互轉換，造成了重複溝通、理解和建模。模型驅動開發，在開發過程的每個階段基於標準和轉換工具，所以每乙個階段的成果，都可以被下乙個階段復用，消除重複。這也是標準的魅力之一吧。
(2) 同一件事物，不同的人各描述了該事物的不同方面，造成他們之間所描述的事物既類似又不同，有重複的地方，又不完全一樣，導致自我重複。
比如，銀行中的使用者資訊模組，在"網上銀行"、"公積金貸款"，和"信用卡系統"中各自都可能有乙個模組，從資料庫、到邏輯、到介面都各自重複一套，他們之間既類似又有一些區別，如需要的資訊不一樣。導致這些模組之間的自我重複。對於此類的自我重複，是由架構設計導致，在架構設計階段沒有按照"元件化"、"服務化"和"層次化"的架構設計，造成在乙個事物不能符合不同模組和系統的需求，並且無法擴充套件。
這種自我重複，在企業的遺留系統和新系統之間尤為明顯。因為大多企業的老系統在構建時由於技術、組織結構等原因，都是採用垂直的渠道架構，即儲存層、邏輯層、展現層完全重新實現，甚至連技術框架都和其他渠道相異。如某銀行業的多渠道應用中，不同渠道（如網上銀行和手機銀行）的邏輯類似，但在兩個系統中重用性不高，存在著大量的自我重複。如下圖左所示：
隨著soa(service oriented architecture)的廣泛使用，再輔助以層次化架構，能有效解決此類問題。重複的元件要被重用，就需要是元件化的，並且能夠被訪問到。ejb、web service以及相應的元件化、基於服務的設計思想，一定程度解決了這些問題，緩和了在企業架構中的重用性問題。
而層次化的架構設計則既是解決架構重複的途徑，也是結果。層次化的架構演變過程，可以在人類社會發展過程中找到似曾相似的影子。在人類社會中，任何事情重複到一定程度，就會產生乙個新的職業或階層，比如，找房子的人多了，就自然會產生中介。在架構設計中也是一樣。任何設計重複到一定程度，就應該抽象出新的層次。這個層次也許可以作為乙個新的元件，也可能做出乙個新的產品。上圖2右邊的架構，是銀行多渠道整合的架構設計，是基於soa架構的、多層次高度重用的架構設計，銀行在新增乙個渠道（如增加atm渠道）時，能夠重用大量的其他渠道的元件。
(3) 沒有自我重複，但重複別人。指乙個功能有很好的免費開源框架或者標準可以依據，但設計開發時沒有採用，而重新發明輪子，導致不能重用已有的標準或開源框架的優勢。記得幾年前參加的乙個企業資訊管理系統的產品開發，該產品從底層mvc框架開始開發，還開發了介面ui控制項、自己的xml流程引擎實現等，然後才是在這個基礎上開發該企業的資訊管理系統。最後結果如何可想而知：投入產出比失衡，以失敗告終。這是乙個典型的"沒有重複自己，但重複標準或免費成熟框架"的例子。在商業中的專業分工、競爭優勢理論和軟體架構思想有很多相通之處。乙個開飯店的，不應該去種大公尺、白菜或養豬，而應該抓住自己的核心競爭優勢，開好飯店。相同的，種菜的、養豬的，也不應該無緣無故跑去開飯店。除非他們各自都想轉行，進入另外的專業化分工領域，同另外領域內公司競爭。在軟體業中也是一樣的道理，每個產品都有其核心競爭力，每個產品都應該把握住本產品的核心競爭力，並投入最大的人力物力去經營。而對於其它的標準、輔助工具、框架或產品等，應該持開放的態度，復用已有的標準、成熟框架或產品。當然，除非你想重新定位你的產品。這種型別的錯誤技術人員經常會犯，但作為產品的架構設計師，應該盡量杜絕這種錯誤的發生。
(4) 開發過程中資訊重複，如軟體過程中用到的工具（專案管理系統、開發工具、測試計畫及用例、build工具、版本管理工具等）之間的資訊重複；還有軟體過程中各種角色的溝通重複，如開發人員報告進度給開發組長、開發組長又重新報告進度給專案經理等。如下圖所示：
對這一型別的自我重複，乙個整合的協作平台能解決問題。基於這個協作平台，軟體過程中所有角色、工具和流程都能無縫的協作，消除了資訊重複和溝通重複，加快開發效率。如下圖所示：所有的工具無縫整合，消除了資訊重複；所有的角色都基於乙個協作平台，能夠實施反映產品的狀態、資訊、各種歷史記錄等，極大降低了溝通重複。
(5) 缺乏重構導致自我重複。這一種自我重複是最幼稚且低階的重複，但在很多產品的**和文件也大量存在。乙個功能在不同模組中重複拷貝使用、物件繼承和組合關係混亂、文件關係混亂等都屬於這一類的問題。對於這一型別的自我重複，對軟體進行持續重構是唯一的好方法。**重構具體請參考《重構》這本書；至於文件重複，大家不妨把《重構》的思想應用於文件，也必有所得。
總結：don't repeat yourself，是軟體開發的最佳實踐，良好的軟體開發應該是非自我重複的，同樣按照非自我重複思想設計開發的軟體，往往是好的軟體。
1、 dry，消除軟體開發的各個階段之間的重複，以客戶和需求為中心，加快開發速度。
2、dry，遵循"元件化"、"服務化"、"層次化"的架構設計，使得架構清晰，層次分明，並易於重用。
3、dry，不自我重複，也不重複別人，特別是標準和成熟的開源框架，使得架構開放，穩定，並減少成本。
4、dry，不重複資訊，不重複溝通，改進管理流程，加快開發速度，達到有效溝通。
5、dry，持續重構**，文件等，保持軟體簡介、清晰，便於維護。
企業架構設計之IFW實踐回顧
筆者幾年前曾參與過一套網路銀行的系統建設以及後續這套系統在信用 雲服務 保險 支付等領域的復用，使用了ifw模型的變體。當時僅僅是根據架構師的設計進行編碼 測試和交付以及後續的維護，沒有對這套模型進行系統化的總結，心中總是有點缺失。這麼多年過去，藉著在組內分享的機會，系統地整理一下這塊的知識，希望對...
系統設計之架構設計
架構設計這個詞聽的非常的多，但真正何謂架構設計呢？可能要你真的來講還真的講不太清楚，很多人都知道架構設計是對系統進行分層 分模組進行設計，但又有多少人知道這步應該怎麼去做呢，往往很多的programmer在剛進入架構設計這個領域的時候，受到以前做模組的那種影響，把自己的眼光限定到了具體的模組實現上去...
系統設計之架構設計
架構設計這個詞聽的非常的多，但真正何謂架構設計呢？可能要你真的來講還真的講不太清楚，很多人都知道架構設計是對系統進行分層 分模組進行設計，但又有多少人知道這步應該怎麼去做呢，往往很多的programmer在剛進入架構設計這個領域的時候，受到以前做模組的那種影響，把自己的眼光限定到了具體的模組實現上去...