在 Hacker News 上獲得接近 500 個點贊的一篇名為《停止學習框架》的文章稱：

我們是程序員，每天都在了解最新的技術，每天都在學習編程語言、框架和庫，因為我們知道的現代編程工具越多越好，對吧？

不停地追隨 Angular、React、Vue、Riot、Ember、Knockout 的腳步還真是一件有意思的事情呢。（譯注：反話）但這其實是在浪費時間！

時間是人類最寶貴的資源。時間是有限的、不可再生的，你可以用錢買任何東西，卻買不了時間。技術，就像時尚，在以光速在變化著。為了趕上它，我們需要跑的非常快。但是這個跑道上沒有終點，所以沒有贏家。

將你的黃金時間用于學習通用技能，那些不會過時的技能。

• 不要學習微服務框架，學習演進式架構（Evolutionary Architecture）。

• 不要學習新的編程語言，學習代碼整潔之道、設計模式、領域驅動設計（DDD）。

• 不要學習 LeSS 和規模化敏捷框架（SAFe），學習精益生產原則。

• 不要學習 Hystrix，學習容錯模式。

• 不要學習 Docker，學成持續交付。

• 不要學習 Angular、React 和 Vue，學習 Web、HTTP 和 REST。

為什么要使用領域驅動設計？

從Eric Evans的《領域驅動設計：軟件核心復雜性應對之道》一書的書名就可以看出這一方法論是為了解決軟件核心復雜性的。也就是說軟件業務越來越復雜了，領域驅動設計可以讓事情變得簡單。而實際情況是：領域驅動設計的門檻很高，沒有很深厚的面向對象編碼能力幾乎不可能實踐成功。

這一說法是否自相矛盾呢？Martin Fowler在PoEAA一書中給了一個有力的解釋：

我們把三層架構等除了領域驅動之外的架構方式都可以歸納為以數據為中心的架構方式，在圖中是黑色的粗實線；領域驅動設計在圖中是綠色的粗實線。

• 當軟件在開發初期，以數據驅動的架構方式非常容易上手，但是隨著業務的增長和項目的推進，軟件開發和維護難度急劇升高。

• 領域驅動設計則在項目初期就處在一個比較難以上手的位置，但是隨著業務的增長和項目的推進，軟件開發和維護難度平滑上升。

這幅圖形象的解釋了領域驅動設計和傳統的軟件架構模式兩者在軟件開發過程中解決復雜性之間的差異。

領域驅動設計的核心是什么？

戰略設計：

說到戰略設計，我們要站在一個比較高的視角來看待這個問題，戰略設計要解決的就是某個領域的問題，所以戰略設計時，我們要構建好領域模型，保證我們的大方向是不會錯的

戰略設計主要從業務視角出發，建立業務領域模型，劃分領域邊界，建立通用語言的限界上下文，限界上下文可以作為微服務設計的參考邊界。

以數據為中心的架構模式

戰術設計 :

戰術設計則是要求我們從業務模型轉向微服務落地 我們會將領域模型中的領域對象與代碼模型中的代碼對象建立映射關系，將業務架構和系統架構進行綁定。當我們去響應業務變化調整業務架構和領域模型時，系統架構也會同時發生調整，并同步建立新的映射關系。也有演進式架構的含義在里面。

說到這里，大家可能對DDD有了一個粗略的，大體的認識，我們可以理解到，DDD能夠幫助我們更好的在微服務的架構中進行合理的拆分，由于DDD要求我們建立標準的業務領域模型，所以DDD也能夠很好地幫助我們設計企業的中臺,DDD是一把利器，幫助我們解決架構中遇到的問題和挑戰。

領域模型

DDD的優勢及未來

DDD是一套完整而系統的設計方法，并非一種架構。它能帶給你從戰略設計到戰術設計的標準設計過程，使得你的設計思路能夠更加清晰，設計過程更加規范，有助于提高技術人的架構設計能力。無論是在新項目中設計微服務，還是將系統從單體架構演進到微服務，DDD 都大有助力。

倘若能一直保持DDD的開放性，保持DDD的獨立性，我覺得在未來的五年乃至十年，DDD仍將煥發生命力，只是它的面貌會更加多姿多彩，甚至超過Eric Evans對DDD的原初定義。畢竟，軟件系統的核心只有兩個：領域和算法。

為了幫助大家更快的了解和熟悉DDD驅動領域設計，這里給大家推薦一門高級架構師Zilor的在線直播課程~從原理到代碼實戰，全程干貨，帶你完整走一遍 DDD+ 微服務設計的全流程，重點講解其中的技術要點、設計原則和注意事項。希望能給對微服務、中臺等分布式架構感興趣的朋友，帶來實質性幫助~

如掃碼添加失敗

請加微信號：ruanmounetzry

超值福利免費送！！

掃碼獲取以上福利

僅限前200名

總結

以上是生活随笔為你收集整理的Hacker News热文：请停止学习框架，学习领域驱动设计（DDD）(获500个点赞)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。