我們根據需求不要急於建立分析模型，而是應該先根據對需求的理解，將系統劃分為多個界限上下文，每個界限上下文為獨立解決業務的一部份的解決方案。
比如乙個電商平台，可以分為買家、賣家、商品、訂單、退貨等幾個界限上下文。劃分界限上下文是非常自然的事情。
比如乙個oa系統，可以分為部門與員工基礎資料、費用管理、內部考試、學習中心、員工考勤、釘釘通知(各種業務事件發生時呼叫釘釘框架傳送訊息)等。
界限上下文通常有三種型別，分別為核心域、支撐域、通用域。
核心域：系統最核心並有複雜業務邏輯的業務界限上下文，比如電商平台的訂單上下文，oa系統的費用管理上下文。
支撐域：系統支撐其他界限上下文的基礎，比如電商平台的商品，oa系統的員工基礎資料。
通用域：需要使用的基礎框架或第三方成熟解決方案，比如oa系統中封裝的釘釘框架上下文、學習中心。
領域驅動設計系列（一） 為何要領域驅動設計？
領域驅動設計最近貌似開始火起來了，越來越多的人開始認識到領域設計的重要性，從我做過的專案來看，似乎歐洲已經有很多的公司開始實施領域驅動設計了，我看領域驅動設計也有些時間了，但是網上不管是文章還是 都顯得太過 高大上 一談領域驅動設計，一大堆的概念一股腦的給你上上來，搞的有點暈頭轉向，而我想在一些中小...
領域驅動設計之我見 領域業務
談到領域驅動設計 ddd 人們很容易想到如下這張圖，那麼是不是你的軟體做了如下的分層設計就是領域驅動設計的了？顯然不是，以下分層只能說明的軟體做了分層架構，領域驅動設計的核心在領域模型，領域模型的核心在業務知識。如果能夠採用物件導向思維將業務抽象為恰當的模型，不管用什麼架構都稱得上領域驅動設計。在大...
領域驅動設計 Understanding DDD
無論有沒有軟體支援,無論軟體是好是壞,世界各地每個領域每天都發生著數以億計可以理解的業務 領域驅動設計是一種設計方法,試 決的問題是軟體的難以理解,難以演化.採用的方法是圍繞業務概念來構建模型.不過你也可以從兩個角度來理解領域驅動設計 作為設計結果的ddd和作為開發方法的ddd,即 what and...