應用分層：
工程結構是一開始最糾結的地方，關於service層能夠幹什麼，層與層之間用什麼DO/PO/DTO，都是很傷腦筋的問題。
狀態圖：關注狀態有多少，狀態切換觸發的條件是什麼
- 用例圖關注：1）用戶角色有哪些。2）用戶可以做哪些事情。
- 用例圖是需求分析階段的
- 活動圖是需求分析後期的。
- 狀態是設計階段的。
- 類圖是開發前的
- 時序圖是開發前的，也可以開發中。
MVC——解耦
- model：模型、數據。對頁面支撐的數據、對數據進行處理的業務邏輯。Service、Dao、pojo類。類比爲廚師
- controller：全盤統籌。類比爲服務員
- view：Jsp、模板、創作頁面。類比爲顧客
表現層：app、windows客戶端、頁面、一個對外開放供其它客戶端調用的api。
通用邏輯層：專門抽取出來的共用、特殊的service層
dao層：使用mybatis框架。
第三方服務：也用於訪問數據，若調用第三方數據，額外有防火層，得將數據、狀態碼轉換爲自己的數據格式和狀態碼（嚴禁引入第三方狀態碼）。
關於分層異常處理
- DAO層：異常類型較多，無需打印日誌。
- Service或Manager層：需記錄出錯的日誌到磁盤，儘可能帶上參數信息，以保護案發現場。
- Web層：不能向上拋異常給客戶，應跳轉到友好錯誤界面、進行友好的錯誤信息提示。
- 開放接口層：將異常處理成錯誤碼和以錯誤信息方式返回。
分層的領域模型：
- DO（Data Object）：對象與數據庫表結構一一對應，通過DAO層向上傳輸數據源對象，是業務邏輯對象，可暴露所有字段，是內部使用，controller層調用service層。例如自己寫的select所返回的查詢結果；如果查詢時多表連接查詢出的結果，也屬於DO範疇和po基本是一個道理。
- DTO（Data Transfer Object）：數據傳輸對象，Service或Manager層向外傳輸的對象，設計數據傳輸（服務器交換數據時，用到的部分數據放入DTO裏），包括對象的序列化和反序列化，而BO中不涉及。DTO可用來接控制層參數。
- BO（Business Object）：非常強的業務屬性概念。實質是業務對象，可以由Service層輸出的封裝業務邏輯的對象。
- Query：可簡單看做接口的入參。數據查詢對象，各層接收上層的查詢請求。注意超過2個參數的查詢封裝，禁止使用Map類來傳輸。
- VO（View Object）：顯示層對象，通常是Web向模板渲染引擎層傳輸的對象。
- ——得能做到區分DO和VO，其餘視情況而定，BO用的不多。
構建-Build
- 傳統：批處理。
- 現在：構建工具，如傳統Ant（打包，不能管理依賴）、主流Maven、新型Gradle。
GAV：工程的座標
- G：groupId
- A：artifactid
- V：version
關於確定jar，不同版本號依賴的是哪一個——聲明仲裁。
- 按照DependencyManager版本聲明進行仲裁。
- 如果沒有仲裁聲明，則按照依賴最短路徑確定版本。
- 如果是相同的路徑，按照第一聲明優先原則。
版本、二方庫規約等
命名方式：主版本號.次版本號.修訂號
- 主版本號：產品方向改變或者大規模API不兼容或者產品架構不兼容升級。
- 次版本號：保持相對兼容性，增加主要功能特性，影響範圍極小的API不兼容修改。
- 修訂號：保持完全兼容性，修復BUG，新增次要功能特性等。
說明：注意起始版本號必須爲：1.0.0，而不是0.0.1。
反例：倉庫內某二方庫版本號從1.0.0.0開始，一直依次默默升級爲1.0.0.64，將完全失去版本的語義信息。
一些其他二方庫引用規約
線上應用不要依賴SNAPSHOT版本
正式發佈的類庫必須去中央倉庫查證，使RELEASE版本號有延續性
正式發佈的類庫版本號不允許覆蓋升級
二方庫的新增或升級，保持除功能點之外的其它jar包仲裁結果不變，即保證升級時使用maven中的resolve命令功能。
二方庫裏定義的枚舉類型，參數中可以使用
日誌設計文檔：
錯誤碼設計文檔：
異常處理設計文檔：