1.1整理需求用例（新平台或多系統需求）
要求描述
完整性概要設計應該覆蓋詳細需求設計
識別系統干係人
找到產品需求功能的使用者，可能是人、軟體
識別需求的關係
需求之間的泛化、包含、擴充套件，以便於模組的劃分
用例圖示例：
用例圖教程：
1.2模組劃分
要求描述
覆蓋當前所有需求
詳細需求設計上的任一需求都能在某模組中找到
模組內聚性
模組包含的需求共同完成乙個領域功能，模組可以單獨開發和測試
模組低耦合
模組間只能通過api建立鏈結，除此鏈結，模組間不需要知道彼此的實現細節
依賴關係：使用系統模組圖描述模組間關係
要求描述
單向依賴
系統或模組之間不能雙向關聯，避免耦合
模組圖示例
協作關係：使用時序圖描述模組間協作關係
要求描述
圖示協作關係
用uml的協作圖描述協作關係，展示時序和輸入輸出
系統協作圖示例
1.3api設計
要求描述
輸入輸出描述
使用rap描述介面詳細功能，**中使用多行注釋
單一輸入
不強制用類進行封裝，建議使用類，方便擴充套件
單一輸出
不強制用類進行封裝，建議使用類，方便擴充套件
多參輸出
建議用類進行封裝
多參輸出
建議用類進行封裝
界定合法輸入
告知呼叫者什麼樣的輸入才合法，比如id不能為空、手機號長度11位
承諾輸出結果
告知呼叫者合法的情況下返回結果一定是什麼
異常情況
區分系統異常和業務異常
不刪除舊介面
如果不確定介面已不使用，不能刪除舊介面，可使用@deprecated
不修改舊介面
如果不確定舊介面被誰使用，則不能修改舊介面
新增優於修改
如果修改介面影響較大，建議直接新增介面，做好介面版本管理
備註：此處api設計為概要
1.4資料庫設計
要求描述
分清資料庫
確定需要涉及哪些資料庫變更
表設計使用powerdesign描述：表名、欄位名、主鍵、是否為空，外來鍵、值約束、預設值，如果有資料冗餘處理，需要說明原因和訪問規則
表關係使用er圖描述實體與實體之間的關係
資料庫er圖示例：
er圖教程：powerdesigner 畫er圖
1.5適配既有系統架構
要求描述
適配既有硬體拓撲結構
盡量沿用，如果不能滿足，提出方案進行評審
適配既有軟體部署位置
盡量沿用，如果不能滿足，提出方案進行評審
適配既有系統環境
盡量沿用，如果不能滿足，提出方案進行評審
適配既有資料庫
盡量沿用，如果不能滿足，提出方案進行評審
適配既有基礎架構
盡量沿用，如果不能滿足，提出方案進行評審
名稱描述
jdkjdk1.7，特殊情況下需要使用jdk1.7以上版本，需要經過架構組確認
rpc框架
dubbo
快取redis
訊息佇列
rocket mq
關係型資料庫
mysql 主備
配置中心
disconf
監控平台
cat日誌平台
elasticsearch+filebeat+kibana
應用容器
tomcat 7、8
定時任務
elastic-job
負載均衡
tengine
規則引擎
drools
檔案系統
oss協調服務
zookeeper
非關係型資料庫
mongodb
詳見：架構規範
架構設計和概要設計
初步再來 下架構設計和概要設計的區別和邊界問題。先談下架構設計 架構設計包括了功能性架構和技術架構設計兩個部分的內容，功能性架構解決業務流程和功能問題，而技術架構解決非功能性需求等問題。兩種架構都包括了動態和靜態兩個方面的內容，對於功能性架構中動態部分為業務流程驅動全域性用例，用例驅動的用例實現等 ...
架構設計和概要設計
初步再來 下架構設計和概要設計的區別和邊界問題。先談下架構設計 架構設計包括了功能性架構和技術架構設計兩個部分的內容，功能性架構解決業務流程和功能問題，而技術架構解決非功能性需求等問題。兩種架構都包括了動態和靜態兩個方面的內容，對於功能性架構中動態部分為業務流程驅動全域性用例，用例驅動的用例實現等 ...
SOA架構設計概要
主要內容也是來自 stevey對amazon和google平台的長篇大論 我們理解的soa必然是通過介面的方式將資料與功能開放出來的，但要想要往平台方向發展，必須保證用且僅用服務介面的形式提供資料和服務 團隊間的程式模組的資訊通訊，都要通過這些介面 除此之外沒有其它的通訊方式。其他形式一概不允許 不...