ENode框架Conference案例分析系列之 - 業務簡介

前言

ENode是一個應用開發框架。經過ENode，咱們能夠方便的開發基於DDD+CQRS+EventSourcing+EDA架構的應用程序。以前我已經寫了不少關於ENode的架構以及設計原理的文章，可是由於沒有和具體的例子結合來進行分析，因此可能不少人仍是沒法理解ENode的功能和設計。因此，接下來，我想經過一個較爲完整的案例來一步步從業務分析到領域模型設計再到代碼實現，以案例的方式講解ENode如何幫助咱們落實DDD的編碼實現。

本文是這個系列的第一篇，因此須要先介紹這個案例的一些業務。

前段時間，我用業餘時間開發了一個DDD的案例，叫Conference。它是一個支持多租戶的會議管理和預約的系統。這個項目不是我我的想出來的，而是微軟的一個CQRS實踐的一個開源項目，項目主頁：http://cqrsjourney.github.io/

Conference業務簡介

Conference是這樣一個系統，它提供了一個在線建立會議以及預訂會議座位的平臺。這個系統的用戶有兩類：1）客戶，能夠建立和管理會議；2）會議座位預約者，能夠預訂會議座位。具體的關鍵業務描述以下：

1. 客戶建立一個會議，並錄入會議的基本信息，好比名稱、時間段、地點，等；會議建立後，系統會爲客戶自動生成一個AccessCode，客戶能夠經過AccessCode訪問本身建立的會議；
2. 客戶定義某個會議的座位類型，能夠定義多個，每一個座位類型包含的信息有：名稱、座位價格、座位數量；
3. 客戶發佈或取消發佈某個會議，當一個會議發佈後，預訂者就能夠在線預訂會議的座位了；若是取消發佈，則該會議對預訂者不可見；只有未發佈狀態的會議才能修改；
4. 預訂者在預訂會議座位時，會生成訂單，訂單須要進行支付纔會生效；
5. 訂單生成後，預訂者能夠有15分鐘的時間付款，超過15分鐘，訂單預約的座位就會回收，容許其餘人預約；
6. 訂單生成後，系統會爲預訂者生成一個AccessCode，用戶能夠經過AccessCode查看本身的訂單；
7. 預訂者成功預訂了座位後，能夠指定每一個座位的實際參會人信息；
8. 客戶（會議的Owner）能夠管理他建立的每一個會議的全部訂單，好比能夠查看該會議的全部訂單以及參會人信息，以方便聯繫參會人；

結束語

經過上面的業務介紹，咱們不難理解，這個系統本質是一個簡易的電子商務系統。它提供了商品管理、下訂單、支付三大功能。你們能夠看到，這個系統沒有用戶註冊、登陸的業務，而是簡單的採用AccessCode來讓用戶訪問本身的數據，由於這是一個學習案例。我之因此選擇這個案例來進行分析，就是由於你們通常對電子商務系統的業務相對比較熟悉，這樣咱們討論就有了必定的基礎。下一篇文章，我想從DDD的角度，分析如何進行戰略設計（劃分子域以及BC）和戰術設計（創建領域模型）。