亚洲XX00视频,亚洲AV无码资源在线观看,无码欧精品亚洲日韩一区

DDD領域驅動設計 - 設計文檔模板

去除一切花俏的建模技巧，我覺得最重要的方向就是去努力分析問題和事物的本質，針對這個本質進行領域建模。這個領域建模，最主要的還是鍛煉的人的事物抽象能力。10個人，建出來的領域模型都不同。本質原因就是大家對同一個問題的理解不同，對事物的本質的理解不同。雖然最終都能解決當前的問題，但是對適應未來需求變化的能力卻是不同。
所以，我們要把時間花在多理解業務上，讓自己成為領域專家，只有這樣，才能充分理解業務。多理解一點業務，你才能更好的抽象出業務本質背后的領域模型。很少有人能做到很快理解業務，并很快針對業務設計出正確的領域模型，至少我是不行。
領域建模需要時間，是一個迭代的過程，人無完人。而時間很多時候也不會很充足，所以，不太可能一步到位把領域設計做的很完美。我們在整體項目規劃的時候可能會有個大的架構設計、業務大圖（邊界思維），但是不可能達到領域設計的粒度，只能是一期一期的完善，到最后可能才會有完整的上面的目錄內容。每一期都需要考慮支持的場景約束、上下文、系統邊界、持續集成的相關設計。設計product, not project。

posted on 2017-02-19 12:14 paulwong 閱讀(754) 評論(0) 編輯收藏所屬分類: DDD


只有注冊用戶登錄后才能發表評論。




網站導航: 博客園 IT新聞 Chat2DB C++博客博問管理
相關文章: 領域驅動設計實戰 DDD領域驅動設計 - 設計文檔模板淺談我對DDD領域驅動設計的理解(轉) DDD CQRS架構和傳統架構的優缺點比較快速理解聚合根、實體、值對象的區別和聯系基于Spring Boot, Axon CQRS/ES,和Docker構建微服務 DDD資源