領域驅動設計系列（一）:爲什麼要領域驅動設計？

前言

領域驅動設計最近貌似開始火起來了，愈來愈多的人開始認識到領域設計的重要性，從我作過的項目來看，彷佛歐洲已經有不少的公司開始實施領域驅動設計了，我看領域驅動設計也有些時間了，可是網上不論是文章仍是代碼，都顯得太過「高大上」，一談領域驅動設計，一大堆的概念一股腦的給你上上來，搞的有點暈頭轉向，而我想在一些中小項目實施領域驅動也遇到了不小的障礙，你們對不少東西都處於一種恐懼的狀態，並且在正真開始實施時，也遇到一些疑問，因此也想和你們交流學習，所以開始在此寫寫對領域驅動的理解，後面會有一些輕量的演進代碼。

爲什麼要領域驅動設計？

簡化數據存儲

領域驅動設計有不少緣由，談到我爲啥要在公司推行領域驅動設計，提及來仍是很好玩的，由於原來基於數據驅動的開發方式，也就是傳統的多層開發架構，你們定義了一堆DAL來操做數據, 在.Net你們通常有兩種使用方式，一種是用ORM像Entity Framework, 另外一種想使用Dapper這樣輕量級的Mapping工具，這些都要把關係型數據轉換爲對象。結果致使如下幾種結果。

• 沒有正確的使用ORM, 致使數據加載過多，致使系統性能不好。
• 爲了解決性能問題，就不加載一些導航屬性，可是卻把DB Entity返回上層，這樣對象的一些屬性爲空，上層使用這個數據時根本不知道什麼時間這個屬性是有值的，這個是很醜陋的是否是？
• 如是又開始使用一些輕量級的數據方法，好比使用Dapper而後本身寫SQL語句，這原本是很不錯的方式，可是大部分人的SQL能力實在不敢恭維，大部分寫出來的SQL語句，甚至比EnityFramework生成的語句還差。

因此，我就想咱們作項目，大部分處理的應該是業務，如何讓程序員從數據存儲，模型轉換的大泥潭裏解放出來，領域驅動設計就進入了個人視線，固然光從數據這個角度還不足以選擇領域驅動設計，用一個NoSQL數據庫是否是就解決了？ 可是NoSQL也有一些問題，好比MongoDB如何更優雅的保證事務以及數據的一致性等。

更多瞭解上下文

咱們不少軟件的問題，你們都知道是需求的問題，也就是客戶的需求咱們很難理解準確，致使程序員更加關注"HOW" 而忽略了"WHAT", 最終作了幾個禮拜甚至更長時間，結果客戶會說:"What?! I told you", 可是客戶告訴個人，咱們理解是不同的。好比客戶說：「 Great job, I love you!」 這個Love確定不是男女之間的Love, 咱們拿到的是一個客戶的需求，他的上下文是什麼？ 好比說：「這個球打的好」， 若是是在打籃球，確定說的事籃球，若是是在打乒乓球確定說的是乒乓球。 而領域驅動設計裏咱們可讓業務人員更多的參與系統，更早的參與系統。

統一語言(Ubiquitous Language)

業務人員和咱們使用同樣的語言，咱們的程序好比讓業務儘可能集中在領域裏，好比在傳統的數據驅動裏，若是說Jack愛Rose, 咱們通常會這麼寫

UserService.Love(Jack, Rose)

可是咱們業務人員很奇怪誰Love誰？ 爲何要UserService?, 若是咱們寫成下面這樣

Jack.Love(Rose)

還有若是咱們用

Company.hire(employee)

來代替

companyservice.hire(company,employee)

這樣咱們就更容易讓業務人員參與進來，並且代碼能夠更易於表示真實的業務場景。