哪些互聯網公司在使用領域驅動設計？

01-25

我個人感覺應用領域驅動設計是有必要的，而且領域驅動設計也可以融合其他的設計思想。我想問問那些國內知名互聯網公司的工程師們，你們有沒有在用領域驅動設計，如果沒有，那你們有什麼理論指導？

DDD是很多best practise，理論與實踐綜合在一起整理而成的一套系統理論，用來方便溝通與討論，其中特彆強調了從業務出發，domain dictate tech implementation。很多資深的工程師和CTO們，未必知道DDD。比如上個月我跟我司一個principle engineer review一個design，我說我用一個transform layer來構成一個DDD的anti-corruption layer來隔離dependent domain的concept。他完全不明白什麼是DDD和anti-corruption layer，但是當我解釋了這個是什麼之後，他表示同意。因為在他來看這種practise他也不知道做過多少次了，只不過從來沒有給這個practise起個名字而已。不要過於糾結於DDD中的名字，戰術，具體技術（這裡具體技術指entity value obj，aggregate，service，repository，event sourcing，CQRS）了解DDD的目的和要解決的問題，才是最重要的，了解為什麼要domain driven才是最重要的。這些DDD要解決的問題和best practise，在無數的公司被無數的人在使用，然而他們有可能根本不知道什麼是DDD。

上面的已經說了很多為什麼ddd不能在國內普及的原因

其實相對於分散式盛行的互聯網，一些並發很小相對技術實現而言更關注業務流程的的企業應用其實更適合ddd，只是這個東西對於猿們來說就相當於8年前的hibernate,3年前的非同步編程，易上手難精通，所以一直處於看上去很美的階段。

比如jdon，從頭到尾都是一個人寫出來，沒有初中級猿地協作。畢竟國內稱得上合格的猿類不多。

就個人經歷和知曉的情況而言，在遊戲行業中ddd是實踐得最多的。因為遊戲中大量用到cache，幾乎所有邏輯都在內存中實現，大部分情況下並不關心數據實時入庫及強一致性。因此非常弱化關係性型db的使用，那麼一旦業務對象拋開了時刻考慮如何寫入到關係型db的這層枷鎖，離ddd就更近了一步

謝邀，我比較懶，一般回答的都比較簡潔，見諒。現在覺得在知乎里的回答沒有個上千字，都不好意思發布，哎，實在是感覺不好。

--------------------------------------------------------------2016-11-29 15:31:10 更新

一年後我更新了這個答案，因為我覺得不管怎麼做設計，都要面對領域模型。

做架構設計，不必計較這些，忘記掉所有的招數和約束，不必在意什麼理論，存在即合理，重在優雅的解決業務問題，或許此間已經形成了你自己的理論。而你的實踐和理論有多牛逼，就看能應付的業務場景有多少多大了。

我的確對DDD不熟悉，但是做系統設計，或多或少都從領域對象出發的。先梳理出領域對象，再梳理出它們之間的關係、聯繫，大都如此。

領域對象最後就成了我們代碼里的DO、Entity，不同場景下還有DTO等。

它們之間的聯繫、聯動，就成了我們代碼里的方法、事務。。。表結構里的一對多、多對多。。。

說實話，之前對領域驅動的理解比較片面，評論里的幾個哥們批評的很對。

這要看如何理解「使用領域驅動設計」，如果是使用「聚合根、實體、值對象、倉庫」，那麼恐怕是很少的，先不說開發人員會不會用，實際上這個層面的領域驅動設計本身也不適合大多應用。

一來，很多應用本身業務邏輯並不複雜，使用「聚合根」等概念並不划算。他們的優勢是能對業務規則提供良好保護，缺點是有一定的規則和複雜度，開發起來沒那麼快，而快對於互聯網行業很重要。

二來，我理解這些概念更多出自面向對象編程風行的那個年代，而現在的開發方法更加豐富了，比如函數式編程等等，沒有必要硬去套這些概念。

但我猜測這些公司多多少少都應用了「限界上下文」，雖然他們可能不是這麼稱呼這種分析方法的。事實上，這是領域驅動設計最精華的部分，強調了模型和通用語言是針對某個上下文的，這樣的專用模型易用但不通用，才能發揮作用並容易維護。我想比如淘寶，涵蓋了產品、訂單、支付這麼多領域，不可能都是用一套通用模型吧，應該是由許許多多的處理特定問題的小應用（限界上下文）協作完成。

總結來說，「聚合根、實體、值對象、倉庫」屬於單個限界上下文的實現範疇，使用的約束比較多；

「限界上下文」則屬於架構設計範疇，是將大型複雜問題分解為若干簡單問題的方法，這個肯定會用到，但有時使用者可能並不知道自己的方法和領域驅動設計有相同的思想。

阿里有項目在用

netfocus - 博客園在推廣，當然這只是一個點

洋碼頭、博客園

還有很多小公司就不說了~

我也覺得公司大了以後，項目便會錯綜複雜。而DDD又是一種思想，開發人員水平參差不齊，並不能使所有項目都完全去使用DDD。

就像敏捷開發、測試驅動開發，也不是所有公司都能完全去照做的。因此，我覺得DDD也會像敏捷一樣一點一點去滲透到項目里，或多或少的使用一些。

看了大牛們的回復，我有個疑問，DDD和並發，和分散式事務有衝突？？

DDD只是一種對於複雜業務的指導思想，與並發、事務應該沒有多大關係吧？

更願意把它當作一個規範、思想，而不是一種實現，DDD具有分治，內聚，OO的特點，這3個特點是保證軟體代碼可維護可擴展的關鍵，如果能寫出符合這3個點的大型軟體代碼，不是DDD也無所謂。像 @阿萊克西斯說的，大部分的架構師在設計時都或多或少的使用了裡面的一些分析方法，有點像生物進化論里的」趨同效應「，對的東西，總是慢慢的被越來越多的人發現。

1，公司層面，我知道支付寶sofa有在推過。

不過只有ddd的個人，沒有DDD的公司。支付寶推ddd的結果導致ddd淪為形式（sofa那套格式），裡面涉及和代碼全是不ddd的。

公司意願是好的，但實施只能是人，能力和理解的問題，難以越俎代庖。

2，個人層面知道jdon有用，我也在用

參見鐵原：什麼是領域驅動開發（domain driven development）？

對於微服務和DDD之間的關係，哪位大牛能詳述下？