領域驅動設計（Thoughtworks洞見）

二零二零年讀完的第二十四本，對書中講到的點都特能感同身受，提到的很多建議都在工作中不斷提煉，但是可惜在公司中並沒有同樣對這個感興趣的同事可以參與討論，有時候我知道問題的癥結跟解決方法但是要往前推的時候並不是那麼容易解析清楚，或許還是那句話“道可道，非常道”坑是要躺過才知道怎麼爬。在技術方面上，我在架構上都已經買好了演進的種子，在上層把控好這個服務便捷跟把領域邊界限定好了，整體就可控了。最後，繼續實踐技術總結。

怎麼說呢，給了推薦，畢竟還是能從裏面學到東西。但是 Thoughtworks 的各種對外的書籍，都是一眼有道理，再看不給看的感覺，經常就是結論之後裏面空空，可能跟他們公司的性質有關係，一般來說後面的內容就屬於付費諮詢了，大概就是文字給你希望，付費幫你落地。

最近正在學習DDD對項目進行拆分，這本書確實給了我一些啓示。 從理論出發落於實踐也許是最好的教學方式，我認爲這本書沒有。 書中的某些理論確實值得學習和思考，但是有很多是作者by experience的總結。難以說放在四海皆准。 收集文章組成的書連貫性不好，某些篇幅索然無味。 更多的告訴讀者what，而沒有着重說明how和why，這讓讀者很難將理論落地。 不過筆記我仍然會試試翻看。

去年工作中重點研究的一個方向就是領域驅動，我對領域驅動的認識從雲裏霧裏到開始有感覺。這本書的很多理念和方法講的比較通俗且具備實操性，今年項目上希望能借鑑起來改善項目提高質量~

本書是一些文章的拼湊，內容不夠系統，預設了很多DDD前提知識，需要讀者具備一定的理論基礎和實踐經驗才能理解作者們分享的心得。

當敏捷宣言的17位簽署者在2001年喊出“響應變化勝於遵循計劃”這樣的口號時，鮮有組織會真正把這句話當回事兒，甚至很多經驗豐富的管理者會認爲好的計劃是成功的一半，遵循計劃就是另外一半。然而在時下的第四次工業革命浪潮中，可能很多管理者已經不會簡單滿足於“響應”，而是選擇主動發起變化了。不確定性管理成了這個時代的主旋律，企業的響應力成了成敗的關鍵。 隨着這種趨勢的深入，架構設計這個技術管理領域也被推到了風暴邊緣。“穩定”這個過去我們用來形容好系統的詞語似乎已經失去原有的含義，很多人開始用“健壯”這個詞語來形容好的系統。比如Netflix公司採用的Chaos Monkey機制隨機主動關停線上服務而不會造成整個服務生態宕機的作法更多的是在測試系統的健壯性，保證不會因爲某個局部的問題而造成全身癱瘓。 然而架構的健壯性卻比較難於定義和測試，以至於很多時候咱們在架構設計上還是在追求穩定性。在一個典型的企業IT組織裏，當你詢問一位資深工程師架構設計時，往往會得到一張搭積木一樣的“架構圖”。 圖的底層是各種數據存儲（從經典的Oracle到大數據標配的Hadoop），圖的中間是類似Kafka這樣的消息管道和傳統的ESB（消息總線），上層則是各種業務應用（包括各種Web應用和移動的APP）。 彷彿這是一個流行的“穩定”架構設計。

從業務出發、面向業務變化是我們現代架構設計成功的關鍵。架構設計的核心實質是保證面對業務變化時我們能夠有足夠快的響應能力。

TW作爲DDD領域的持續推動者, 本書算不上一本領域驅動的入門書, 但非常推薦有一定業務架構基礎, 準備嘗試領域驅動具體落地的實踐者好好的看看這本書, 這裏類似一個大雜燴收集了很多領域驅動的信息, 把過往的文章信息做了一次整合. 其中四色建模法提供了一個非常形象的例子. 建議先去了解一定基礎概念再來看這本書.

書全名叫領域驅動設計，但只是收錄了各種文章，沒有體系化的介紹和思考，也沒沒有自身的核心觀點

本書實質上是一些博客合集，作爲想了解領域模型是怎麼回事，還是很有幫助的。裏面提到兩個領域模型的實踐方法，還是讓人眼前一亮的。當然，領域驅動設計要做好，還是儘可能找機會去實踐推演，，可以結合自己現有業務系統去推演，不斷歷練自己設計思維，提升領域設計能力。 對作者提到的一個觀點也很是認同，作爲技術人員，不能單純關注技術維度，也需要去關注下業務價值，畢竟技術和業務密不可分。最後提到的技術債也是感同身受，作爲一名程序員，儘量不要欠小的技術債。