前言
由碼代碼到軟件設計，所需要的思維方法發生了變化，某些在碼代碼時佔比比較小的思維方法在軟件設計中變得至關重要。
軟件概要設計剛開始學習不久，本文僅僅基於本人當前的認識。
大原則
軟件設計最本質的原則（在我看來）是經濟學十大原理中的第一條：人們面臨權衡取捨（trade-off）。
碼代碼不會有這個意識，在這個階段接受到的是具體的任務，框架已經選好並搭建完畢了，數據庫選定了，相關的技術也都已經定好，要做的只剩下完成某個需求，不復雜的情況 CRUD 就可以搞定，業務複雜的情況下加點設計模式也就搞定了。
軟件設計時工程師面臨更加複雜的情況。
軟件設計定義
根據維基百科對軟件設計Software Design 的定義：
Software design is the process by which an agent creates a specification of a software artifact, intended to accomplish goals, using a set of primitive components and subject to constraints.
關鍵詞 specification，software artifact， components，constraints
概要設計定義
- A formal description of a system, or a detailed plan of the system at component level to guide its implementation
- The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.
概要設計關注的是組件結構，相互的關係以及設計中的原則和指導方針。
概要設計的藝術
在進行概要設計時需要從抽象、圖表、文檔三方面進行思考。
抽象
抽象是尋找事務最本質的特徵的過程。以前寫過一篇抽象的文章，就抽象這個概念進行了一些討論，此次關注的是抽象在概要設計時所起到的啓發作用。
譬如設計一個用戶服務，最終設計圖如下： 
這是經常看到的架構圖/設計圖，但是設計圖裏已經將所有的可能都確定了，就像數學題直接給出了答案，無助於瞭解設計的過程。
真正有助於啓發的是在更高一層的抽象上思考服務設計。
在這個設計圖上來再進一步思考就到了技術選型的思考於分析，數據存儲是選用 RDBMS 還是 NoSQL？Config Server 選用 Spring Cloud Config 還是 攜程開源的 Apollo？Request Handling Service 選用 Java 還是 Go？這就需要在當前的環境下來對所有的情況進行考慮，也就是前面所說的大原則：trade-off.
所以設計不是給一個解決方案，而是給出幾個選擇，再選擇中選擇最優解。
圖表
碼代碼只需要在頭腦中就可以思考所有的情況，然後具現爲代碼，因爲這是單人完成的任務。概要設計則不然，設計完成之後還需要由其他人將其實現。因此設計的溝通屬性更強一些。 圖表就是利於溝通的強大工具。
在抽象中給出了兩個設計圖，在作圖時也需要時刻記住抽象原則。 判斷圖表做的好與不好，可分析圖表所表現的架構是否是在同一個抽象層次上。
文檔
If you can’t explain it simply, you don’t understand it well enough. - Albert Einstein
文檔是將所思所想表達出來的載體。如果不能簡潔的寫出來，那說明你沒有完全的瞭解它。
文檔也是梳理的自身的一種手段，就像寫博客一樣，需要將思考有條理的表達出來，僅僅停留在腦海中是不夠的。
總結
不同系統需要不同的設計方案，此文更偏於方法層面，具體系統還需要具體分析。