1樓：kevin zou
領域驅動就是物件導向分析和設計，其產出的領域模型指的是描述業務資料和邏輯的物件模型（可以想象成UML的類圖）。
傳統的結構化分析和設計，產出關係模型，也就是資料庫中的table架構，只是乙個資料模型。
二者的差異就在於後者只有資料，而前者不僅有資料，還有資料的建立邏輯。
資料模型描述資料的結構，方便查詢和使用資料，但因無法描述資料的建立過程，因此往往需要其它文件輔助說明。因為沒有邏輯，可能會造成系統分析不徹底，一些需求要到開發階段才能驗證。
而物件模型，不僅有資料，還有邏輯，甚至有的領域驅動設計方法，如：
kevin zou：從面向資料庫到領域驅動設計
能夠在分析階段就提供可以實際執行的領域模型，其資料以及邏輯(訊息介面)完全聚焦在業務邏輯上，加強了物件導向分析的能力，以及需求的確定性，讓後續開發更順暢。
2樓：chljapan
產品（服務）、屬性，角色，規則（具體業務規則）、流程，計算
看懂的話，你就可以做到真正的模型驅動開發了，注意資料庫的設計，那是成敗的關鍵。
3樓：鐵原
鐵原：什麼是領域驅動開發（domain driven development）？
模型是1 2 3 4 的總和。
1 2 3 4 是什麼？是不變性的總和啊
模型即不變性。
概念的不變部分，關係的不變部分，邏輯的不變部分。大致如此。
舉個例子，Netty框架的解決的問題（領域）是什麼？
是阻塞導致的IO和Thread資源利用率的問題——即使Io和Thread的速率不匹配的問題。
咋抽象1，Io ->Channel
2，Thread - >Handler
3，（速率不匹配）解決方案：eventLoop
4樓：賈朝陽
模型是本著特定目的對實物的抽象，簡化。領域模型是為了用軟體協助處理領域中的事而做的抽象和簡化。
DDD強調的就是統一語言，減少概念翻譯成本。所以模型是有著領域名稱的實體，聚合，領域服務等。
5樓：元認知
首先應該看到「領域驅動」是一種「層次架構」：面向業務人員的領域層次和開發人員的「軟體」層次。現實中，軟體系統開發已有許多建模工具、方法和語言。
現在的問題在於採用什麼語言、方法和工具建立領域模型？
好的系統架構是這樣的：
統一的建模框架，針對不同的「角色」，構建不同層次的模型，模型之間可以「平穩過渡」，成果系統可以執行，改進或者重建業務模式。
總之，這是乙個可以迴圈發展的知識、資料和應用系統。
這麼說，還是有點抽象。看到「知識管理」主題，比較贊同「應當以自己的應用場景去架構自己的知識世界」的觀點。將這個觀點應用到領域驅動架構，應當以公司的業務領域去架構自己的業務模式和應用系統。
本人的經驗表明，這兩者分屬不同的「世界」，但是，又有交叉。特別是，當今網際網路公司的業務已經是跨界、跨領域了，更需要這種基於業務知識的應用系統。2017-8-21
6樓：leision
利用類，介面，盡量模擬接近現實世界，DDD的核心思想就是，看起來，這好像和現實世界一樣，簡單點說，比如乙個human類，那必然具備，吃飯，睡覺，等各種方法和身高等各種屬性。並且這些吃飯，睡覺方法必須內部消化，而解開以前極大依靠資料庫的耦合。
如何理解領域驅動設計的領域一詞？
金旭亮 領域與具體開發技術無關。就是你的軟體系統要解決的實際問題相關的所有東西的集合。比如你要開發乙個賣書的網上書店系統，那麼如何進貨 如何決定優惠規則 如何安排物流 如何管理客戶級別，如何分析銷售資料等等，這直接與業務相關的所有東西都歸屬於 領域 DDD就是說你得先把 領域 中涉及到的資料 流程 ...
三維建模中，如何優化模型的佈線？
Zhuang 分享一點經驗，一起學習,可能有些你都知道了，但我也稍微囉嗦一些，見諒。不管是N gons還是走線，就是edge flows，都需要通關多加練習來掌握。建模開始前，先觀察你的參照物，考慮一下大概線要怎麼走才自然，才不會彆扭混亂，也考慮一下這個物體是什麼形狀，可以拆分成幾個部分嗎這樣的問題...
微服務架構中如何解決連表查詢的問題？
太上玄元道君 得看你們的場景，如果是OLTP業務，那就去呼叫其他服務的介面，通過分布式事務去做最終一致性。如果是OLAP就簡單了，把你所有分庫的資料同步到乙個從庫中，在從庫中進行分析 小憤青 把資料以 customer 類似這樣的方式,儲存在ES上,資料庫盡量就不做特別多的多表關聯查詢了.至於後續取...