設計文檔模板： 一些其他的思考： 去除一切花俏的建模技巧，我覺得最重要的方向就是去努力分析問題和事物的本質，針對這個本質進行領域建模。這個領域建模，最主要的還是鍛煉的人的事物抽象能力。10個人，建出來的領域模型都不同。本質原因就是大家對同一個問題的理解不同，對事物的本質的理解不同。雖然最終都能解決當 ...
設計文檔模板：
- 系統背景和定位
- 業務需求描述
- 系統用例圖
- 關鍵業務流程圖
- 領域語言整理，主要是整理領域中的各種術語的定義，名詞解釋
- 領域劃分（分析出子域、核心域、支撐域）
- 每個子域的領域模型設計（實體、值對象、聚合、領域事件，需要註意的是：領域模型是需要抽象的，要分析業務本質，而不是簡單的直接對需求進行建模）
- 領域模型詳細說明（如為什麼這樣設計的原因、模型內對象的關係、各種業務規則、數據一致性規則等）
- 領域服務、倉儲、工廠設計
- Saga流程設計
- 場景走查（講述如何通過領域模型、領域服務、倉儲、Saga流程等完成系統用例以及關鍵業務流程的）
- 架構設計（如傳統三層架構、經典四層架構、CQRS/ES架構）
一些其他的思考：
- 去除一切花俏的建模技巧，我覺得最重要的方向就是去努力分析問題和事物的本質，針對這個本質進行領域建模。這個領域建模，最主要的還是鍛煉的人的事物抽象能力。10個人，建出來的領域模型都不同。本質原因就是大家對同一個問題的理解不同，對事物的本質的理解不同。雖然最終都能解決當前的問題，但是對適應未來需求變化的能力卻是不同。
- 所以，我們要把時間花在多理解業務上，讓自己成為領域專家，只有這樣，才能充分理解業務。多理解一點業務，你才能更好的抽象出業務本質最後的領域模型。
- 領域建模是一個迭代的過程，人無完人，時間也很多時候不是很充足。所以，不太可能一步到位把領域設計做的很完美，會有一個持續的過程。整體項目規劃的時候可能會有個大的架構設計、業務大圖，但是不可能達到領域設計的粒度，只能是一期一期的完善，到最後可能才會有完整的上面的目錄內容。每一期都需要考慮支持的場景約束、上下文、系統邊界、持續集成的相關設計。設計product, not project。
