領域驅動介紹
什麼是軟體
軟體是一種被建立用來幫助我們處理現代生活中複雜問題的工具，它不是終極目标，而是到達目的的一種方法。這個目的通常是非常實際和真實的事情，比如我們使用軟體控制空中交通。這個例子說明了軟體的直接聯系和實際應用性。我們想從一個地方飛到另一個地方，需要通過使用複雜的機器達到目的，于是我們制造軟體來協調那些在空中飛行的數以千計的飛機。是以，作為軟體架構師，你需要了解軟體的本質和作用，并且将這種了解貫穿于你的工作中，以確定你的軟體能夠達到實際應用的目的。
軟體必須是實際和有用的，否則我們不會花那麼多時間和資源去建立它。軟體的實際應用性和有用性是與我們生活的某個方面密切相關的。一個有用的軟體包不能和現實，也就是假定能幫助我們管理的領域，分割開來。相反，它們緊密相連。是以，作為軟體架構師，你需要明确軟體的實際應用性和有用性，并且将這種了解貫穿于你的工作中，以確定你的軟體能夠達到實際應用的目的。同時，你需要注重軟體的整體架構和設計，以確定軟體的可靠性、可擴充性、可維護性和安全性。這樣，你的軟體才能夠真正地滿足使用者的需求，為使用者提供價值。
與其他藝術一樣，軟體設計不能通過定理和公式以一門精确科學的方式被教授和學習。通過軟體建立的過程，我們可以發現有用的規律和技巧，但是我們也許永遠不能提供一個準确的方法，以滿足從現實世界映射到代碼模型的需要。是以，軟體設計需要結合實踐和經驗，以及創造性和直覺。軟體産品既包括設計和開發它的那些人的個人勞動，也包括緻力于它發端和成長的那些人的某些上司力和洞察力（或者沒有這個）。是以，作為軟體架構師，你需要注重軟體的整體設計和開發過程，同時也需要注重團隊的上司力和協作能力，以確定軟體能夠達到高品質的标準，并且能夠持續發展和成長。
領域驅動設計是什麼？
領域驅動模型的方向
軟體開發通常被應用到真實世界中已經存在的自動化流程，或者給真實的業務問題提供解決方案，即要自動化的業務流程或者可以用軟體解決的現實問題。是以，軟體開發需要深入了解所在的領域，才能夠為業務問題提供更好的解決方案。從一開始，我們就必須明白軟體脫胎于領域，并跟領域密切相關。隻有了解領域中的業務流程和需求，才能夠更好地設計和開發出符合實際需要的軟體産品。
同時，你也需要注意到軟體是由代碼最終構成的，但是軟體開發過程不僅僅是編寫代碼。有時候，我們會被代碼所誘惑，在它上面花費了太多的時間，将軟體看作是簡單的對象或者方法。但是，軟體開發涉及到的問題遠不止代碼。
實踐案例
缺乏領域概念的執行層
假設以汽車制造來類比，參與汽車制造的勞工會專門負責汽車的某個部件，但這樣做的後果是勞工們通常對整體的汽車制造流程缺乏了解。他們可能将汽車視為一大堆需要固定在一起的零件的集合體，但一輛汽車的意義遠不隻于此。
填充領域模型的設計層
一輛好車起源于一個好的創意，開始于認真制定的規格說明，然後再傳遞給設計。
經曆若幹道設計工序，用上幾個月甚至幾年的時間去設計、修改、精化直至完美，直至它反映出最初的願景。
測試以及最後的落地
設計的過程也不全然是在紙上進行的，許多的設計工作包括制模、在極端條件下對它們進行測試，以驗證它們是否能工作等。設計會根據測試的結果做出修改。
汽車最終被傳遞到生産線上，在那裡，所有的部件已經就緒，然後被組裝到一起。
領域知識存在的意義
軟體開發也是一樣。我們不能直接坐下來敲代碼。當然也可以這樣做，在開發價值不大的軟體時。但我們不能用這種方法開發複雜的軟體。
為了建立一個好軟體，你必須知道這個軟體究竟是什麼。在你充分了解金融業務是什麼之前，你是做不出一個好的銀行業軟體系統的，你必須了解銀行業的領域。
豐富的領域知識對于複雜的銀行業務軟體開發至關重要。軟體架構師、分析師或開發人員都不如銀行的業務人員更了解銀行業務系統，因為他們是銀行業務系統的專家，知道所有的細節、困難、問題和規章等。在啟動一個軟體項目時，我們應該關注軟體涉及的領域，因為軟體的最終目的是增進特定領域，為了達到這個目的，軟體需要與要服務的領域和諧相處，否則會給領域引入麻煩，産生障礙、災難甚至導緻混亂。
軟體和領域的關系
為了讓軟體和領域和諧相處，最佳的方式是讓軟體成為領域的反射，即具現領域裡重要的核心概念和元素，并精确實作它們之間的關系。是以，我們需要對領域進行模組化。
對領域進行模組化
建立領域的抽象是非常重要的，因為沒有植根于領域的軟體不能很好地應對變化。從領域開始着手，我們需要為領域建立一個抽象，在腦海中建立一個藍圖。
對領域建立藍圖
領域中的藍圖是一個模型，一個關于領域的模型。按照Eric Evans的觀點，領域模型不是一幅具體的圖，它是那幅圖要極力去傳達的那個思想。它也不是一個領域專家頭腦中的知識，而是一個經過嚴格組織并進行選擇性抽象的知識。
是以，我們需要通過與領域專家交流，學習領域知識，并将其轉換成一個清晰的、抽象的模型。這個模型能夠描繪和傳達領域的本質，讓軟體能夠更好地服務于領域。最終，通過精心編寫的代碼和一段英語句子，我們能夠達到将模型轉換成軟體的目的。
領域模型
領域模型是對目标領域的内部展現方式，是設計和開發過程中非常必要的。
模型設計的重要性
模型是軟體設計中最基礎的部分，因為它能夠幫助我們處理複雜問題。我們的所有領域思考都被彙總到這個模型中，但它必須超越我們的頭腦，否則它就無法發揮作用。是以，我們需要與領域專家、資深的設計人員和開發人員進行交流，以確定模型的準确性和完整性。模型是軟體的根本，但我們需要找到一些方法來表現它，讓它能夠與其他事物進行交流。在這個過程中，我們需要共享知識和資訊，并不斷改進模型，使其更加精确、完整、無二義性。有許多方式可以實作這一點，其中常見的一種方式是将模型圖形化，例如使用圖、用例、畫和圖檔等。另一種方式是通過書寫來表達我們對領域的願景。還有一種方式是使用語言，我們可以為要交流的領域内的特定問題建立一種語言。在接下來的章節中，我們将詳細講解這些方法，但主要觀點是我們需要用模型來交流。
領域模型的知識範圍
在設計過程中，我們需要對模型的很多方面進行引用。然而，我們周圍的世界中有着海量的内容等待我們去處理，甚至一個特定的領域所包含的内容都遠遠超出了人腦一次可以處理的範疇。
領域模型的系統化處理
需要組織資訊，将其系統化，将其分割成小的資訊塊，并将這些資訊塊分類放到邏輯子產品中。
在處理資訊時，我們需要忽略領域中的很多部分，因為領域包含了如此之多的資訊，不能一下子放到一個模型中。
保留和剔除内容範圍
而且，我們也不必考慮其中的很多部分。這對于模型本身也是一個挑戰：要保留哪些内容，放棄哪些内容呢？這在軟體建立過程中屬于設計部分的範疇。
優化領域模型
例如，銀行業軟體需要跟蹤客戶的住址，但不需要關心客戶的眼睛是什麼顔色的。這是一個很明顯的例子，但其他的例子可能不會如此明顯。是以，在設計和開發過程中，我們需要不斷地審查和完善模型，以確定其準确反映領域的本質，進而讓軟體能夠更好地服務于領域。
面向人群
無論你是企業架構師、團隊上司者、項目經理還是進階軟體開發人員，本文章都可以幫助你正确了解領域驅動設計，并同時實作你的業務目标和技術目标。
重點決策人群：團隊上司者、技術架構師、項目經理和業務架構師。
主題方向
Java、.NET、SOA、Agile、Ruby 和 Architecture。
推薦學習
《領域驅動設計——軟體核心複雜性應對之道》（Addison-Wesley 2004，已由清華大學出版社翻譯出版）。
領域驅動設計——軟體核心複雜性應對之道
它提供了一個模組化和設計技術的系統，成功的團隊應用這一系統可以組裝有業務需求的複雜軟體系統，并使系統在增大時仍然保持靈活。
Domain Language 是一個咨詢小組，它指導和訓練團隊實施領域驅動設計，幫助他們使自己的開發工作對業務而言更有生産力和更有價值。
領域驅動設計建議
- 親力親為，模型需要代碼支援。
- 專注于具體場景，将抽象思維應用到具體案例中。
- 不要試圖對所有事情都進行領域驅動設計。可以畫一張範圍表，然後決定哪些應該進行領域驅動設計，哪些不需要。不必擔心邊界之外的事情。
- 不斷進行實驗，期望能夠發現錯誤。模型的創造過程需要不斷嘗試和改進。