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.分析多個場景之間的交互過程與方式，以及交互過程中產生的影響，確實協作的方式，畫出 上下文映射圖 ，比如（訂單和支付場景，支付成功之后，通知訂單，改變狀態）
