適用於所有人的領域驅動設計
這是一位使用DDD已經五年的經驗分享：
我最近一直在談論領域驅動設計（DDD），無論是在聚會還是與客戶，所以我想我會寫下我的想法，看看它是否有幫助。
現在，很多人都從技術角度撰寫了有關DDD的文章，所以我不打算這樣做，而是從非技術角度討論DDD，這是其他人的DDD。
解決方案始終超支
設計和構建解決方案並非易事。它永遠不會順利進行，即使它按時完成（永遠不會），解決方案通常也是無效的，需要經常大幅度地改變。這導致更多的延遲，更大的預算，甚至更大的問題。
為什麼會這種情況繼續發生？
Complex vs Complicated
例如，“稅收”很複雜complicated，有許多交織規則和流程，但一旦你知道如何應用流程對付它們，你就解決了這個問題。它變得程式化; 不需要再考慮。按照這個過程，你會沒事的。
進行企業軟體開發根本不是這種複雜complicated，而是complex，有太多的未知數。換句話說，它很複雜。如果你仔細想想，這是相當明顯的。如果存在一個流程就能建立企業，那麼每個人都會使用這個流程，辦企業就是零風險。
複雜complex問題無法控制，ofollow,noindex" target="_blank">只能進行管理 。然而，我們仍然試圖將企業軟體開發視為一個流程，因為我們真的希望它成為一個流程。只要看看“敏捷”*和“精益”的受歡迎程度，特別是那些以市場為導向的，以流程為導向的產品，它們會重新強化這種錯覺（而且它們也不起作用）。這是一廂情願的想法。
DDD承認這一事實，而不是專注於嚴格的流程和硬規則（即一種尺寸適合所有解決方案），它提出了管理和消除歧義的技術。祕密不在於一個流程，它是關於你試圖解決的問題的迭代。
專注於（正確）問題
在DDD中領域，即問題及其產生的知識/活動，是其他一切的驅動因素。所有解決方案都來自問題域，因此將核心域置於中心自然會帶來更好的解決方案。
例如，假設您是線上新聞商家。您的“核心”域（驅動您的業務的域）是內容生成，其他一切都是次要的。通過更快地生成更好的內容，將會不斷髮展您的業務。但是，如果你專注於解決調整影象大小的問題（並聘請一大堆開發人員來編寫軟體），那麼你可能不會發展你的業務。
DDD帶來了清晰度，我們能夠專注的清晰度，。
與專家交談
如果您想了解問題，那麼您需要與領域專家交談。領域專家是比任何人都更瞭解問題的人，他們能夠告訴你什麼是重要的，什麼不是。
在大多陣列織中，領域專家不是構建解決方案的人。DDD有助於彌合領域專家知道的內容與構建解決方案的人之間的知識差距。
這就是為什麼大量的DDD技術與技術無關，而是專注於人和方法來發現複雜性和模糊性。如果我們都在同一頻道上，那麼前進就更容易了。
建立共識
獲得清晰度的一個關鍵方法是建立對問題的共同理解，即領域模型。如果每個人的頭腦中都有相同的模型，那麼就沒有歧義。它有助於我們避免過度複雜化我們的解決方案，或者更糟糕的是，構建錯誤的解決方案（例如上面的影象縮放器）。
統一語言
語言是DDD的核心。我們使用語言來表達我們的想法，探索問題並定義解決方案。如果領域是複雜的，那麼這種語言將是豐富而複雜的，具有自己的微妙和細微差別。
問題是，您企業中的大多數人可能不會共享該語言。相反，他們使用自己的語言來解決問題，這很好。然而，當兩個或更多人嘗試使用不同語言進行通訊而沒有意識到它時出現問題，例如相同的單詞但具有不同的含義。這導致歧義，並且是導致錯誤和誤解的主要原因。
加入這種混亂中的人越多，問題就越嚴重。
解決方案是讓每個人與領域專家密切合作，以便在業務定義語言時理解語言，並找出這些語言邊界和存在位置，即何時在不同的上下文中使用這個單詞(在什麼時間什麼場景的單詞所指的意義)。這使每個人都能夠進行通訊（即具有共享域模型），從而減少了孤島，更好的協作和更簡單的解決方案。
解決方案反映了您對問題的理解
你構建的任何解決方案都直接反映了你對問題的理解程度。如果解決方案是好的，那麼您瞭解您的領域，如果方案不好，說明你沒有理解領域。這就是為什麼快速迭代如此重要，它是關於收緊反饋迴圈和迭代問題，而不是在你第一次嘗試時就能構建正確的解決方案（從未發生）。
通過將解決方案作為反饋，可以進行進一步的討論，並確定您是否接近，從而產生更好的領域模型，從而產生新的解決方案，從而反饋您對問題的理解。它是迴圈的，它鼓勵我們更好地理解我們正在做的事情，解決方案的不會像變戲法一下子有，一下子沒有了。
更快的反饋才是更好的反饋
越快地測試解決方案越好，這並不意味著需要馬上構建軟體，如果通過構建軟體後進行測試才發現背離需求，這就最昂貴的測試方式。相反，為什麼不用樣機甚至筆和紙原型解決方案呢？你將在最短時間內得到相同的反饋，DDD鼓勵前期發現和迭代，而不是為了它而編寫軟體。
這並不是說DDD不會談論很多軟體，它肯定會，並且它有很多編寫模式，但軟體不是核心。DDD的一個常見格言是最好的軟體不是軟體。因為軟體本身增加了複雜性，所以如果你能避免這種複雜性，你應該這樣不要立即構建軟體。一個優秀的DDD從業者將嘗試找到問題的現有解決方案，只有在它帶來最大價值的情況下才會回到定製軟體上。
自我提升
DDD是關於理解和迭代問題的問題。這是迴圈的，這意味著DDD經常用於瞭解自身並改進自身。您可以想象這個反饋迴圈的速度有多快，DDD從業者總是在迭代，發現和命名模式和技術。隨著時間的推移它會變得更好。
結論
DDD將業務及其領域置於應有的位置。我已經使用DDD 5年了，我不得不說我建立有用解決方案的能力已大大提高。這有助於我磨練我需要理解和迭代問題的技巧和技能。如果你想更好地建立解決方案，我會全心全意地推薦DDD。