又一次寫架構設計文檔，現在至少也是寫過6、7次架構設計文檔了，每次寫架構設計文檔自己都有感覺，每次的想法都不同，所以每次的目錄結構都有所改動(盡管公司有規范，但我會按自己的理解進行重整)，應該說覺得寫了這么多次以來，每次都覺得當時的那次是寫的最好的，慢慢的也明白自己在寫架構文檔方面已經在不斷的進步了，其實我認為，能不能寫出架構文檔很能反應出設計師是否真正的掌握了架構的設計，很多時候覺得架構設計文檔沒什么寫的其實已經表明設計師其實對架構并不是那么的理解，在理解了后要寫出來真的是一發不可收拾，都可以寫很多，因為要明白架構設計文檔的對象，架構文檔的作用，盡管現在很多情況下架構文檔都是拿來糊弄用戶，但我覺得作為設計師還是應該寫出一份合格的架構設計文檔，架構設計文檔對于整個項目的實現具有很大的指導意義，寫架構設計文檔能讓設計師真正的仔細梳理整個系統的架構設計，不會是那種臨時突然想出的東西。
這次在寫架構設計文檔中也開始仔細的考慮架構設計文檔到底需要體現什么呢？其次需要明白到底何謂架構，其實我覺得一個形象的說法就是骨架，每個人、每棟房子都需要有骨架，基于這個骨架可實現用戶的功能需求以及非功能需求，那么就可以說這是個成功的架構，我覺得在架構設計文檔中最重要的是體現出對于系統需求的共性的分析，抽象形成系統的底層支撐子系統(注意，這個子系統是系統業務的共性，而不是具體的功能模塊，具體的功能模塊是基于此支撐子系統進行搭建的)，同時列出系統的非功能性需求，提出在架構級別的應對策略，在經過這個架構分析過程后，根據系統結構是C/S、B/S可提出一個底層架構體系，如B/S采用MVC思想搭建的架構體系，在M進行劃分形成N層體系，在做出了底層架構體系設計后將之上架構分析中產生的支撐子系統與之進行融合，同時結合非功能性需求的應對策略，在這個情況下系統的架構圖就產生了，^_^，經過這樣的過程你系統的架構圖就不會是無緣無故產生出來的，在架構圖產生后此時就需要做技術的映射，因為在架構圖的底層架構體系中列出來的是layer，那么每個layer其設計模型是怎么樣的、每個layer的依賴是怎么解決的，在解決完了這個部分后需要對之上的支撐子系統進行設計模型、接口的描述，在完成了這些后即可繪制系統的部署視圖、邏輯視圖以及物理視圖，重要的是需體現出整個系統的需求是如何基于這個架構體系來實現的，在完成了之上的過程后整個架構設計過程可以算是完成了大半部分，在這之后進行支撐子系統的模塊劃分以及系統功能模塊的劃分，劃分原則依據功能內聚來進行，同時也需考慮架構體系的設計約束，在劃分完畢后即產生了系統的模塊視圖，同時需標明模塊的接口關系，在此圖繪制完畢后按模塊對模塊的職責進行描述，同時對其接口做出規范，至此整個架構設計文檔才算是比較完整的完成了，^_^，這樣寫下來我想這份架構設計文檔想薄都難呀，架構設計文檔作為整個系統后續的設計約束以及方向指導而存在。
這是在這次寫架構設計文檔后的一些感想，總體來說我覺得最重要的仍然是需要明確的知道架構設計文檔的目的，何謂架構，架構設計的過程，架構對于需求的滿足，在這之后可進行模塊的概要設計，模塊的概要設計其實同樣是一個由繁化簡的過程，產生出關鍵類以及類的接口設計，詳細設計則是具體的對象設計以及接口實現。