注意，團隊在交流領域驅動設計問題時，不應該只是對建模活動的產出物進行討論，建模的過程同樣非常重要
這個所謂「領域專家」不是乙個頭銜，也不是對技能級別的要求，它其實就是乙個指代，代表「懂業務」的人：可以是客
戶，可以是 product owner，可以是業務分析師，可以是產品經理，也可以是懂業務的開發人員，甚至可以是乙個負責業
務分析的團隊
從業務粒度看，應用服務的每個公開方法會對應乙個具有業務價值的業務場景或者說用例
在軟體開發領域，沒有什麼一勞永逸的實現，也沒有什麼放之四海而皆準的標準，必須結合具體的業務場景做出合理的決
策，無論建模和設計再怎麼完美，也需要通過落地的檢驗才知道好還是壞。任何脫離具體業務場景的問題分析，都是空談
；任何不落地的完美方案，都是浮誇
針對現實世界的問題域建立抽象的模型形成解決方案，這個過程視軟體複雜度而定，可能會非常漫長。這其間需要迭代的
分析、設計和實現，逐步浮現出最終可行的方案，構建滿足需求的軟體。從問題域到解決方案域，或許有多種途徑或手段
，然而針對複雜問題域，通過建立抽象的模型來對映現實世界的多樣性，就好似通過數學公式來求解一般
模型的重要性並不體現在它的表現形式，而在於它傳遞的知識
整個建模過程中主要開展的活動稱之為「建模活動」，並統一歸納為分析活動、設計活動與實現活動。每一次建模活動都
是對知識的一次提煉和轉換，產出的成果就是各個建模活動的模型
不僅僅是建模活動會對模型帶來影響，設計者在面對業務需求時，關注的視角不同，抽象的設計思想不同，也會導致模型
的不同，這就形成了從建模視角產生的模型分類。如果我們是以資料為核心，關注資料實體的樣式和它們之間的關係，由
此建立的模型就是「資料模型」。如果我們需要為系統外部的客戶端提供服務，關注的是客戶端發起的請求以及服務返回
的響應，由此建立的模型就是「服務模型」。而領域驅動設計則強調以領域為中心，通過識別領域物件來表達業務系統的
領域知識包括業務流程、業務規則和約束關係，由此建立的模型就是「領域模型」
C 學習摘要之 一
一 c 的特點 1 語法簡潔 c 不允許直接記憶體操作 c 沒有指標 c 的關鍵字更加明了.2 物件導向設計 c 中的每種型別都可以當作是物件 c 只允許單繼承,也沒有全域性變數和全域性常數,所有的一切都必須封裝在 乙個類中,使 具有更好的可讀性,差減少命名衝突的可能.3 與web緊密結合 網路服務...
DDD學習（一） 通用語言
ddd是領域驅動設計 domain driven design 的縮寫，我們需要關注的是為什麼要用它，誰來用它，後面將要學到什麼樣的概念和知識來運用它？英語作為世界通用語言，不論你是哪國人，出國在外會一些基本的英語應該可以與其他國家的人進行交流。同樣，我們如果在領域專家和開發人員之間也能建立一種語言...
DDD理論學習系列（5） 統一建模語言
1.引言 上一節講解了領域模型，領域模型主要是將業務中涉及到的概念以物件導向的思想進行抽象，抽象出實體物件，確定實體所對應的方法和屬性，以及實體之間的關係。然後將這些實體和實體之間的關係以某種形式 比如uml 圖形 文字描述等 展現出來。而領域模型是領域建模的結果，那如何建模呢？我們可以借助於uml...