Conference業務簡介
Conference是這樣一個系統，它提供了一個線上建立會議以及預訂會議座位的平臺。這個系統的使用者有兩類：
1：客戶，可以建立和管理會議。
2：會議座位預定者，可以預訂會議座位。
具體的關鍵業務描述如下：
1.客戶登陸系統，客戶可以建立一個會議，並錄入會議的基本資訊，比如名稱、時間段、地點，參會人數等。
2.客戶定義某個會議的座位型別，可以定義多個，每個座位型別包含的資訊有：名稱、座位價格、座位數量 ，根據座位型別自動生成座位編號。
3.客戶釋出或取消釋出某個會議，當一個會議釋出後，預訂者就可以線上預訂會議的座位了；如果取消釋出，則該會議對預訂者不可見。
4.預訂者在預訂會議座位時，會生成訂單，訂單需要進行支付才會生效。
5.訂單生成後，預訂者可以有15分鐘的時間付款，超過15分鐘，訂單預定的座位就會回收，允許其他人預定。
6.預訂者成功預訂了座位後，可以指定每個座位的實際參會人資訊；
7.客戶（會議的Owner）可以管理他建立的每個會議的所有訂單，比如可以檢視該會議的所有訂單以及參會人資訊，以方便聯絡參會人；
這個案例是湯總的Conference案例，案例地址： https://www.cnblogs.com/netfocus/p/4591407.html ，案例原始碼地址：https://github.com/tangxuehua/Conference
這個案例是湯總的部落格，這裡有一些小改動，因為自己前面寫了一個RBAC許可權的簡單小DEMO，可能會融入進來，以前都是拿到需求基本上都是直接建表，開發，很少分析，第一次真正的嘗試，希望大家能指出缺點，一起交流溝通。
後面會寫出這個案例Demo，打算從最基礎的開始，因為在寫的過程中一定會有收穫，帶個問題去解決，總比不去嘗試的好，看起來簡單的東西，一去實踐會發現困難重重，看起來難的東西，不斷的去嘗試，會發現其實並沒有想象的難
業務流程梳理，上下文劃分
1.發現業務概念，畫出業務流程圖
2.找出業務場景，根據角色，畫出用例圖 （使用者故事），根據場景的語義相關性，以及業務相關性，將場景歸類 （將業務分類，不要太過於糾結，後面分析可以完善）限界上下文
3.分析每一個業務場景，找出場景中的參與者 ，參與者的基本特徵 ，分析場景中互動的過程，識別業務場景中的規則，分析狀態變化的影響，比如（取消會議，對預定者不可見），狀態比較複雜時：可以考慮畫出狀態變遷的流程圖或者以其他方式表達出變化的過程，比如（訂單狀態的變化），識別出聚合根，實體，值物件 ，領域服務 ，領域事件
4.分析多個場景之間的互動過程與方式，以及互動過程中產生的影響，確實協作的方式，畫出 上下文對映圖 ，比如（訂單和支付場景，支付成功之後，通知訂單，改變狀態）
一：發現業務概念，畫出業務流程圖
二：找出業務場景，根據角色，畫出用例圖 （使用者故事），根據場景的語義相關性，以及業務相關性，將場景歸類 （將業務分類，不要太過於糾結，後面分析可以完善）限界上下文
業務場景：
1，客戶建立會議 2，客戶定義會議座位型別，生成座位號 3，客戶釋出會議 4，客戶取消會議 5，預定者預定會議 6，生成訂單 7，訂單支付 8，指定座位參會人資訊
用例圖：
場景歸類：
三：分析每一個業務場景，找出場景中的參與者 ，參與者的基本特徵 ，分析場景中互動的過程，識別業務場景中的規則，分析狀態變化的影響，比如（取消會議，對預定者不可見），狀態比較複雜時：可以考慮畫出狀態變遷的流程圖或者以其他方式表達出變化的過程，比如（訂單狀態的變化），識別出聚合根，實體，值物件 ，領域服務 ，領域事件
ConferenceContext
一：客戶建立會議
參與者：客戶 ，會議 ，座位型別 ，座位
客戶 Customer：Id ，CustomerId ，CustomerName ，CustomerAddress ，CustomerPassWord （聚合根）
會議 Conference：Id ，ConferenceName ，ConferencePublishStatus , ConferenceStrartTime , ConferenceEndTime , ConferenceAddress，ConferenceContent ，CustomerId ，ConferenceParticipantNum，SeatTypeList （聚合根）
規則:
1，客戶必須登陸系統，建立會議時，客戶必須在系統中存在
二：客戶定義座位型別
參與者：客戶 ，會議 ，座位型別 ，座位
座位型別 SeatType：Id ，SeatTypeName ，SeatTypePrice ，SeatTypeNum ，ConferenceId , SeatList 實體
座位 Seat：Id ，SeatNumber , SeatTypeId 實體
規則:
1，客戶定義座位型別的數量，不能超過會議的參會人數
2，座位編號隨機生成，不允許出現重複編號，最大編號不能超過會議參會人數
互動過程以及影響：座位型別成功後，根據規則生成座位號
三:客戶釋出會議，取消會議
參議者：客戶 ，會議
作為會議的狀態
規則:
3，客戶沒有定義座位型別，不能釋出會議
4，釋出會議，對預定者可見 ，取消會議，對預訂者不可見
互動過程以及影響：釋出會議後，會改變會議的狀態為：已釋出，對預定者可見，取消會議，會改變會議的狀態為：未釋出 ，對預訂者不可見
預訂者在預訂會議座位，生成訂單，訂單需要進行支付才會生效
1，預定者，登陸會議系統
2，瀏覽已釋出的會議
3，選擇要預定的會議
4，選擇要預定的會議座位型別
4，選擇要預定的座位（可以選擇多個座位）
5，點選提交，生成訂單
6，系統處理訂單
7，進入支付的頁面，使用者確認支付資訊
8，使用者點選確認支付，
9，系統處理支付，成功時：修改支付的狀態為：已支付，傳送一個事件通知訂單，訂單扣除會議座位，修改訂單的狀態為：支付訂單成功
失敗時：修改支付的狀態為：支付失敗，傳送一個事件通知訂單，修改訂單的狀態為：支付訂單失敗，回收會議座位
10，使用者點選拒絕支付，修改支付的狀態為：已拒絕，傳送一個事件通知訂單，訂單回收會議座位，修改訂單的狀態為：拒絕支付
11，訂單超過15分鐘未支付，修改訂單的狀態為：支付已超時
ScheduledContext
預定會議座位 ,生成訂單
參與者：預定者 ，訂單 ，訂單明細，會議 ，會議座位型別 ，會議座位
預定者（PredestineUser）：Id ，PredestineUserName ，PredestineUserPhone ，PredestineUserPassWord 聚合根
訂單 （Order）：Id , ConferenceId , PredestineUserId , OrderTotalPrice , CreateTime , OrderStatus ，OrderItemList
訂單明細（OrderItem）Id ，OrderId ，SeatId ，SeatPrice
規則：
1，會議的狀態必須是釋出的狀態
2，訂單中必須包含一條訂單明細的資訊
3，預定座位時檢測座位是否被選擇
4，預定成功後，15分鐘必須支付，過期回收預定的座位
訂單的狀態：
1.已生成訂單 （初始化狀態）
2.預定座位成功 （預定成功，預扣會議座位，記錄預定成功的時間，修改訂單狀態為：預定座位成功）
3.預定座位失敗 （預定失敗，修改訂單狀態為：預定座位失敗）
4.支付已超時 （訂單支付超時，回收的會議座位，修改訂單狀態為：支付已超時）
5.支付訂單成功 （扣除會議座位，修改訂單狀態為：支付訂單成功）
6.拒絕支付 （預定者拒絕支付，回收會議座位，修改訂單狀態為：拒絕支付）
PayContext
支付訂單
參與者：訂單 ，支付
支付（Pay）：Id ，OrderId ，PayPrice , PayStatus , PayCreateTime 聚合根
支付明細（PayItem）: Id , PayId , SeatId , SeatPrice 實體
規則：
1.支付時驗證餘額
支付的狀態:1, 待支付 2, 支付成功 3, 拒絕支付 4, 支付失敗
互動過程：
1，系統處理支付，成功時：修改支付的狀態為：已支付，傳送一個事件通知訂單，訂單扣除會議座位，修改訂單的狀態為：支付訂單成功
失敗時：修改支付的狀態為：支付失敗，傳送一個事件通知訂單，訂單回收會議座位，修改訂單的狀態為：支付訂單失敗
2，使用者點選拒絕支付，修改支付的狀態為：已拒絕，傳送一個事件通知訂單，訂單回收的會議座位，修改訂單的狀態為：拒絕支付
3，訂單超過15分鐘未支付，修改訂單的狀態為：支付已超時
指定座位實際參會人資訊
參與者：訂單 ，座位 ，參會人
訂單座位（OrderSeat）：Id ，OrderId ，ParticipantName ，ParticipantPhone 聚合根
4.分析多個場景之間的互動過程與方式，以及互動過程中產生的影響，確實協作的方式，畫出 上下文對映圖 ，比如（訂單和支付場景，支付成功之後，通知訂單，改變狀態）
