讓我們暫時告別一下 ASP.NET Core 先介紹一下這個虛擬項目。因為我的主要目的是通過一個項目，全面學習一下 ASP.NET Core，所以這個項目時一個很簡單的，不具備實際應用價值的虛擬項目，但是項目會盡可能用到 Web 程序設計的常用技術。
熟悉商品混凝土生產的朋友都知道，在這個領域常用的軟件有兩種，一個是混凝土生產線的生產控制軟件，主要負責監控生產線的運行和按照生產和工藝流程，自動執行生產任務。這個軟件一般是廠家自己開發或委托外包開發的。另外一種是生產管理軟件，就是混凝土行業中常說的 ERP（名字有點大）,一般是專業軟件公司提供。ERP（原諒我使用這個名字）根據生產計划生成生產任務在通過接口（大部分是通過一個中間數據庫）把任務推送（存儲）到生產控制軟件(中間數據庫),生產任務軟件接收（從中間數據庫讀取）到任務然后自動運行。
混凝土生產上有着多個存儲倉，存儲各種物料，而生產任務中包含着各種物料使用情況的配方。一個混凝土生產工廠，一般有多條生產線，而為了應對不同的生產工藝要求，不同的生產線有時會存儲不同的物料。而ERP 在發送生產任務時，是靠人工來確定某個生產線是夠存儲需要的物料。這個虛擬項目就是在 ERP 的任務推送節后面增加一套管道機制，通過不同的管道過濾掉不適合的生產線，最后在通過各個生產線的等待生產的任務隊列，自動負載平衡，選擇最適合的生產線。
這套管道機制應該方便的支持增加和刪除管道，達到任務調度的靈活配置。這樣我們就可以把新的任務過濾邏輯通過類似中間件的技術添加到整個管道中。
這個虛擬項目的主要是為了學習 ASP.NET Core，索引領域模型設計的盡量簡單，但是為了保證項目與實際的盡量貼近，也值得我們好好思考一下領域模型。
說到 領域模型就不得不提到分層架構，站在桌面程序員的視角和Web 方面，分層架構沒有大的區別，尤其現在微軟在 ASP.NET Core提供大量的技術框架支撐分層架構(MVC,EF Core,依賴注入等)。在這個項目里，我們也毫不例外的使用DDD的三層架構。在表示層，因為這個項目設想中要想管道一樣可以快速的接入到攪拌站ERP和生產控制之間，所以表示層被設計為時髦的兩個部分組成：管理界面和用於接入的服務API。在數據層，主要提供從另兩個方面獲取數據源：數據庫和其他服務的API ，在部署時要根據ERP和生產控制軟件的數據發布方式進行選擇和配置，當然選擇和配置服務層要用到依賴注入。最后是用於封裝業務邏輯的領域模型,業務邏輯是個挺操蛋的詞(Martin Fowler 語，至少意思差不多). 使用DDD方式時，領域模型和數據層的映射是個麻煩事，這個留在數據訪問層在討論。
盡管業務邏輯是個很操蛋的詞，但是不可否認領域模型作為整個軟件的核心價值和靈魂值得我們認真去思考。做過項目的朋友都有體會，如果數據映射（ORM）是個技術問題的話，領域模型的設計更像一個哲學問題。 我們經常會碰到下面的問題：
領域模型設計的不合理，這種軟件很難真正嵌入到客戶的管理流程或價值鏈中，用戶在使用這種軟件是就像騎着阿凡提的毛驢或者開着絕地求生里被打爆輪胎的蹦蹦車一樣，雖然有載具了，但是它永遠不會按你想要的方向行駛。還有就是個別用戶會提出特別各奇葩的業務邏輯。這些奇葩的需求或許會轉換成你最不想看到的需求清單。但有時這些奇葩的需求有時確實能提升客戶價值鏈上的某個環節，或者適應客戶的某些管理流程。在做項目時還會遇到很多各種各樣的問題。大部分業務邏輯問題都指向兩個方面，一個是對客戶的價值鏈或管理流程理解不清晰，導致領域模型設計的不合理，第二個是領域模型的擴展性不好，不能對模型進行快速的擴展。大部分第二種情況是第一種的擴展，想想如果客戶的管理流程確實支持某種擴展和修改，那我們的領域模型為什么不能支持呢。
作為系統設計人員，我們不應該相信或者說依賴市場部門提供的需求清單。很難想想這些需求清單能夠清晰的描述客戶的領域模型和價值鏈。我們常說要找到用戶背后真正的需求。如果是企業應用程序，用戶本身是企業的價值鏈和流程的一部分，用戶的需求不能脫離企業的價值鏈和流程，他是需求僅僅是在完成企業流程或實現價值鏈的同事滿足一下自己的價值提升，舉個例子說，使用財務管理軟件的用戶的需求不可能脫離這個企業的財務管理制度，他的個人需求可能是在使用這個軟件是能更方便更快，或者是顯得他更專業，好向老板證明他的價值。實現個人的需求更過的是靠UI 和門面對象(Facde)的支持，而領域模型更應該真實准確的反應企業的流程和價值鏈。
在完成一個好用的項目后，項目開發人員幾乎都能成為至少半個領域專家，這要得益於他在項目開發過程中不斷的和用戶交流，再把企業的領域模型用代碼重構。企業的流程本身就是一個模型，只不過系統設計人員要通過與用戶的交流學習它，在通過自己的語言(UML，編程語言)再把他重構。Eric Evans再《領域驅動設計》中提到過可以通過用UML創建的領域模型和用戶交流，我從來沒嘗試過，不過我堅信，如果你能用 UML 圖和用戶交流，那么你的領域模型設計的十分成功。
PS：寫東西真累，這幾年深受焦慮症的困擾，身體一直不好，甚至影響到思維能力和語言表達能力，最近身體好轉，想通過堅持寫博客慢慢鍛煉思維能力和語言表達能力，所以文章的條例和語言有些混亂，請見諒！
PS：原創不易，水平有限，內容漏洞百出，請轉發的網站和朋友注明出處。