前言
ENode是一個應用開發框架。通過ENode，我們可以方便的開發基於DDD+CQRS+EventSourcing+EDA架構的應用程序。之前我已經寫了很多關於ENode的架構以及設計原理的文章，但是因為沒有和具體的例子結合來進行分析，所以可能很多人還是無法理解ENode的功能和設計。所以，接下來，我想通過一個較為完整的案例來一步步從業務分析到領域模型設計再到代碼實現，以案例的方式講解ENode如何幫助我們落實DDD的編碼實現。
本文是這個系列的第一篇，所以需要先介紹這個案例的一些業務。
前段時間，我用業余時間開發了一個DDD的案例，叫Conference。它是一個支持多租戶的會議管理和預定的系統。這個項目不是我個人想出來的，而是微軟的一個CQRS實踐的一個開源項目，項目主頁：http://cqrsjourney.github.io/
Conference業務簡介
Conference是這樣一個系統，它提供了一個在線創建會議以及預訂會議座位的平台。這個系統的用戶有兩類：1）客戶，可以創建和管理會議；2）會議座位預定者，可以預訂會議座位。具體的關鍵業務描述如下：
- 客戶創建一個會議，並錄入會議的基本信息，比如名稱、時間段、地點，等；會議創建后，系統會為客戶自動生成一個AccessCode，客戶可以通過AccessCode訪問自己創建的會議；
- 客戶定義某個會議的座位類型，可以定義多個，每個座位類型包含的信息有：名稱、座位價格、座位數量；
- 客戶發布或取消發布某個會議，當一個會議發布后，預訂者就可以在線預訂會議的座位了；如果取消發布，則該會議對預訂者不可見；只有未發布狀態的會議才能修改；
- 預訂者在預訂會議座位時，會生成訂單，訂單需要進行支付才會生效；
- 訂單生成后，預訂者可以有15分鍾的時間付款，超過15分鍾，訂單預定的座位就會回收，允許其他人預定；
- 訂單生成后，系統會為預訂者生成一個AccessCode，用戶可以通過AccessCode查看自己的訂單；
- 預訂者成功預訂了座位后，可以指定每個座位的實際參會人信息；
- 客戶（會議的Owner）可以管理他創建的每個會議的所有訂單，比如可以查看該會議的所有訂單以及參會人信息，以方便聯系參會人；
結束語
通過上面的業務介紹，我們不難理解，這個系統本質是一個簡易的電子商務系統。它提供了商品管理、下訂單、支付三大功能。大家可以看到，這個系統沒有用戶注冊、登錄的業務，而是簡單的采用AccessCode來讓用戶訪問自己的數據，因為這是一個學習案例。我之所以選擇這個案例來進行分析，就是因為大家一般對電子商務系統的業務相對比較熟悉，這樣我們討論就有了一定的基礎。下一篇文章，我想從DDD的角度，分析如何進行戰略設計（划分子域以及BC）和戰術設計（建立領域模型）。