軟體開發比一般的產品開發還要困難，一開始使用者並不清楚他們所需要的軟體需求，所以也無法告訴軟體設計者，而這些需求也很難預測出來，同時還有需求變動的風險。
因此，針對需求的不確定，軟體設計的方式應該做一些調整。從為需求而設計轉變成為延緩(Postponement)的設計策略，也就是為開發後續開發活動（實作、測試、組裝、配置）預留空間而設計，於是DTx(Design for xxx)的概念於是應運而生。這樣設計方式的好處是增加變化的彈性，當需求改變或確認以後，只要修改或進行差異化的實作，而設計是針對共通模組進行設計，模組化與差異化中間透過抽象類別或界面來達到去除需求變動所造成的衝擊或耦合關係，抽象類別與界面就是所謂的減震點(Decouple Point)。
也許有人認為這樣設計軟體並不容易，但對於設計而言，比目的、策略更重要的是而是設計所抱持的態度。不是為應付客戶需求而設計，而是滿足使用者最大利益及權衡技術成本間的最佳考量。有人會覺得，軟體多變的特質可能不容易作到模組化，但大量客製化會應用模組化的概念，不論產品開發及服務皆適用，而軟體設計本質是屬於服務，所以當然是適用的。
Please follow and like us:
您好，
我剛剛進入職場，最近組長要求我將UI以模組化來設計並提出自己的想法。以前在學校沒有接受過這樣的訓練，請問如何起步？謝謝
Hi Andrew，
依據我在職場的經驗，很多人都會說模組化，但大家對這個名詞或有不同。因此，我建議您先弄清楚組長說的模組化是什麼？想解決什麼問題？這樣才能知道您該如何達成任務。
供參考。
真是巧，跟Andrew的情況很類似，我也被要求要設計一套模組化的”UI平台”，但我總覺得以沒經驗的人來說，模組化的過程應該是先把軟體開發的目標達成以後，再回頭看能夠怎麼把已經開發好的東西拆解成能夠reuse的模組，才是最有效率的。但主管一直要我們先模組化再來開發，這樣子的話到底該怎麼做我卻完全沒頭緒。
Hi Eason:
先模組化設計然後再開發資訊系統這個先後順序是沒有錯的!
因為如果先開發好系統然後再進行模組化的話,那你將會發現原系統可能需要大改才行!而這並不符合成本考量!
只不過軟體模組化真的有那麼容易嗎?老實說並不簡單!
而您的主管要求你要先模組化我認為主要是要你嘗試著模組化設計資訊系統, 而至於達成度如何, 則儘力而為便可!
這裡介紹一個網址提供你參考, 你或許可以從中發現模組化的概念!
參考資料 http://www.gavin.url.tw/MyBook.asp
Hi Gavin，
感謝您提供對模組化的意見。不過依照我的經驗來看，模組化是可能 top-down 或 bottom-up 方向的，端看你模組化的目的為何？
前者的好處是專注於業務概念模組，後者的好處為了節省成本專注於元件的再利用。當然，架構改變的成本考量很重要，但如果太遷就現有架構，那也不能稱為模組化。
因此，模組化端看你的目標與方向而決定模組化的策略；top-down 的適合 well-known 的架構，而 bottom-up 則適合架構不明的問題，由逐步演進而發展出適合的架構。