一、前言
本篇文章會簡要介紹領域驅動設計能做什么，以作為多篇介紹領域驅動設計文章的開篇。后面會使用領域驅動設計的英文縮寫 DDD。之所以開篇介紹 DDD 能做什么，而不是介紹是什么，原因是后者答案很容易找，只需 Google 一下。而介紹 DDD 能做什么，則可以從實踐的角度介紹學習和使用 DDD 的必要性。
整體而言，DDD 還是一門偏小眾的技術，了解者比例不高，更多的人也還沒有意識到它的重要性。這也是寫此篇文章的一個重要原因。
當然，雖然全篇不會介紹什么是 DDD，但是一句話介紹還是少不了：領域驅動設計是一種思想，用來指導復雜的軟件系統的設計。正如那本同名書的副標題 ——《軟件核心復雜性應對之道》。所以，領域驅動設計的思想是值得每一位從事軟件系統開發，尤其是業務系統開發的同學了解學習的。
接下來簡單介紹一下 DDD 在軟件開發各方面中所能起到的作用。
二、DDD 的作用
1. 需求討論
軟件開發的很多問題其實源于需求討論階段。需求討論不清、對需求的誤解，等等，都會從一開始就對軟件開發造成負面影響。
那 DDD 如何可以解決這一個問題？DDD 解決這一問題的方法的核心是 Ubiquitous Language —— 通用語言。
DDD 指出，對業務知識抽象建模而形成的領域模型應當成為軟件開發交流過程中使用的通用語言。對于同一個業務概念，需求文檔和代碼實現中應該使用同一個詞語去表述。不僅表面上的命名需要一致，背后的含義也應當是一致的。
這么做原因在于，軟件開發過程中，同一個詞，在產品經理和工程師的腦中，可能有著不一致的含義和理解。雖說這種不一致一般不至于差出十萬八千里，但在復雜的系統開發中，即便是細小的差異，經過需求的組合以及時間的積累，最終會導致比較大的差異。而這種差異會對后來的軟件開發造成越來越大的麻煩。
而在軟件開發中應用 DDD，則可以避免這種問題的發生。
2. 系統設計
現在的業務系統的開發，使用的技術有了很大的進步，但是很多系統的設計似乎同十幾年前并沒有太大差別。雖然大家所使用的語言，如 Java、Python、Javascript、Go 等，都或多或少的包含了面向對象的特性，但大部分程序還是以面向過程的思維被設計。而這會導致很多系統設計層面的問題，例如過于復雜、龐大的業務層。
我對系統設計的看法是：對于一個系統的整體設計，更多的應當是使用面向對象的思想，面向過程的思想更多的是應用在具體功能設計上。
在面向對象設計的實際應用方面，DDD 能夠提供非常好的實踐性指導。這就是 DDD 在系統設計方面的意義。
3. 接口設計
在我工作過的項目中，接口設計常常是一個難題。接口不同于代碼實現，代碼實現可以經常修改，但接口一旦發布就很難修改了。所以，接口的設計需要非常慎重的考慮。
如何設計接口呢？在這方面，REST 是一個很好的實踐。當然我不是說 REST 能解決所有的接口設計問題，確實有很多接口不適合用 REST 設計，也有很多接口使用類似但非標準的 REST 接口形式設計。但我建議，在設計接口時請認真考慮 REST 風格。
在使用 REST 風格設計接口時，需要考慮的重要問題包括確定系統中有哪些 Resource、這些 Resource 之間的關系是什么？
其實 REST 接口中的 Resource 其實可以與領域驅動設計中的實體互相等同。如果一個系統設計使用了領域驅動設計，那確定 Resource，以及它們之間的關系也就不是難事。自然，設計出合理的接口也就變得更加容易。
五、小結
大家在討論技術問題時，往往會關注新和大的話題，比如某種新技術、新框架，或者某某系統的高可用架構設計、雙11、大促系統設計等等。
這樣的題目顯然更吸引眼球。雖然這些高大上的內容是大家在工作中需要考慮的內容，也很重要，但是不應因此忽視平時工作更常遇見的問題 —— 如何設計好復雜的業務系統。
如果不能解決好業務系統的復雜性問題，那些如高可用、高并發、多機房容災等等的高大上的技術改進工作實施起來也會變得異常困難。最重要的是，如果整個團隊被業務問題搞得焦頭爛額時，還有多少精力和熱情投入到技術改進工作呢？
所以，從上面這個角度講，領域驅動設計解決的不僅是業務系統的復雜性問題。
對于前面講到的內容，我會在后續的文章中做更詳細的介紹。
