定義：在乙個孤立系統裡，如果沒有外力做功，其總混亂度（熵）會不斷增大。
這裡面有三個詞非常重要：孤立系統、無外力做功、總混亂度（熵）。
首先我們來解釋什麼是「熵」。
熵（entropy），最早在2023年由德國物理學家克勞修斯提出，用以度量乙個系統「內在的混亂程度」。
你可以理解為，系統中的無性能量。
比如物質總是向著熵增演化，屋子不收拾會變亂，手機會越來越卡，耳機線會凌亂，熱水會慢慢變涼，太陽會不斷燃燒衰變……直到宇宙的盡頭——熱寂。
它也左右著國家和企業的發展規律，讓組織變得臃腫，缺乏效率和創新；它左右著個人的方方面面，讓我們安于懶散、難以堅持、難以自律……
那麼這還有辦法可解嗎？
從定義來說，熵增的條件有兩個：封閉系統＋無外力做功。
只要打破這兩個條件，我們就有可能實現熵減。
聽起來好抽象，怎麼理解？
反熵增，即熵減。是通過系統之外的第三者對其「做功」，實現對孤立系統的「熵轉移」，使得原系統的熵總量減少；熵減可以使系統從混亂恢復有序。
也許我們可以從生命裡得到啟示，整個生命的發展就是一部負熵的歷史。
薛丁格說：生命以負熵為食。也就是說，生命的維持和發展，是以造成環境的熵增加（亦即攝走負熵）為代價的。
在軟體開發、維護過程中。軟體的生命力總是從最初的理想狀態，逐步趨向於複雜、混亂和無序狀態發展，直到軟體不可維護而被迫下線或重構。這種損壞軟體質量的因素的逐步增長，叫做軟體的熵增現象。
軟體熵增的表現：
**混亂、新人不易上手
**高度冗餘，復用性低，開發效率低
擴充套件和修改困難，牽一發動全身
業務資料錯亂
程式效能低下
系統難以移置
bug率居高不下
其它…軟體熵增的根本導因是：客觀世界的熵增導致軟體開發複雜化。那麼，如何進行軟體系統反熵增？ 答案是通過『做功』控制這種複雜性。
做功方式有很多，比如：分層架構，開發模式，物件導向，中介軟體等等。但是這些從純技術上控制複雜度。
但控制複雜性的關鍵是有乙個好的領域模型，這個模型不應該僅僅停留在領域的表面，而是要 透過表象抓住領域的實質結構，從而為軟體開發人員提供他們所需的支援。
軟體的核心是其為使用者解決領域相關的問題的能力。所有其他特性，不管有多麼重要，都要服務於這個基本目的。當領域很複雜時，這是一項艱鉅的任務，要求高水平技術人員的共同努力。 開發人員必須鑽研領域以獲取業務知識。他們必須磨礪其建模技巧，並精通領域設計。
然而，在大多數軟體專案中，這些問題並未引起足夠的重視。大部分有才能的開發人員對學習與他們的工作領域有關的知識不感興趣，更不會下力氣去擴充套件自己的領域建模技巧。技術人員喜歡那些能夠提高其技能的可量化問題。領域工作很繁雜，而且要求掌握很多複雜的新知識，而這些新知識看似對提高計算機科學家的能力並無裨益。
相反，技術人才更願意從事精細的框架工作，試圖用技術來解決領域問題。他們把學習領域知識和領域建模的工作留給別人去做。軟體核心的複雜性需要我們直接去面對和解決，如果不這樣做，則可能導致工作重點的偏離。
DDD 領域驅動設計是什麼？
最近幾年，微服務的設計思想，架構方案非常流行，能夠很大程度上保證我們的高效能和高可用，可是微服務設計過程中往往會面臨邊界如何劃定的問題 這個時候就需要一種理論指導，這時候來自2004年 埃里克 埃文斯 eric evans 的領域驅動設計理論能夠幫助我們更好的進行拆和分，也是微服務架構實踐中非常核心...
DDD領域驅動設計
公司裡面敏捷專案要講ddd領域驅動設計，加緊學習了一下，找了一些資料研究。eric evans的 domain driven design領域驅動設計 簡稱ddd，evans ddd是一套綜合軟體系統分析和設計的物件導向建模方法，本站jdon.com是國內公開最早討論ddd 之一，可訂閱 ddd專題...
DDD（領域驅動設計）
domain 領域 driven 驅動 design 設計 由eric evans最先提出，目的是對軟體所涉及到的領域進行建模，以應對系統規模過大時引起的軟體複雜性的問題。整個過程大概是這樣 開發團隊和領域專家一起通過 通用語言 ubiquitous language 去理解和消化領域知識，從領域知...