旅程1：我們的領域：Contoso會議管理系統
起點:我們從哪里來，我們帶來了什么，誰將與我們同行?“
只要前進，我願意去任何地方。” --大衛•利文斯通
本章介紹了一個虛構的公司Contoso。它描述了Contoso計划推出的會議管理系統，這是一個新的在線服務，可以使其他公司或個人通過此系統組織和管理自己的會議和活動。本章從高層次描述了新系統的一些功能和非功能需求，以及為什么Contoso希望使用CQRS和Event Sourcing實現部分功能。與任何考慮此過程的公司一樣，有許多問題需要思考和挑戰，特別是這是Contoso第一次同時使用CQRS和Event Sourcing。接下來的章節將逐步展示Contoso是如何設計和構建其會議管理系統的。
另外，本章還介紹了一個虛構的專家小組來評論開發工作。
Contoso公司
Contoso是一家新興的ISV公司，擁有大約20名員工，專門使用微軟技術開發解決方案。Contoso的開發人員熟悉各種微軟產品和技術，包括.Net Framework、ASP.NET MVC和Microsoft Azure。一些開發人員以前有使用領域驅動設計(DDD)方法的經驗，但是他們以前都沒有使用過CQRS模式。
會議管理系統應用程序是Contoso想要推向市場的首批創新在線服務之一。作為一家初創企業，Contoso希望用最少的硬件和IT人員投資來開發和推出這些服務。為了開始擴大市場份額，Contoso想要快速進入市場，但是沒有時間實現第一個版本中所有計划的功能。所以，重要的是，它采用的體系結構要能夠輕松地適應更改和增強，同時對系統的現有用戶的影響最小。Contoso選擇將應用程序部署在Azure上，以利用其隨需求增長而擴展應用程序的能力。
這次CQRS之旅誰將和我們同行
如前所述，本指南和隨附的參考實現里描述了這次CQRS之旅。一個專家小組將在我們進行的過程中對我們的開發工作發表意見。其中包括CQRS專家、軟件架構師、開發人員、領域專家、IT專家和業務經理。他們都會從自己的角度進行評論。
| 人物 | 角色描述 |
|---|---|
 |
Gary是一位CQRS專家。他確保基於CQRS的解決方案可以為公司工作，並提供切實的好處。他是一個謹慎的人，理由很充分。 ”定義CQRS模式很簡單。實現CQRS模式所能帶來的好處並不總是那么簡單。“ |
 |
Jana是一名軟件架構師。她設計應用程序的總體結構。她的觀點既切合實際又具有戰略意義。換句話說，她不僅考慮現在需要什么技術方法，還考慮公司未來需要什么方向。Jana從事過使用DDD的項目。 “平衡公司、用戶、It組織、開發人員和我們所依賴的技術平台的需求並不容易。” |
 |
Markus是一個軟件開發人員，他是CQRS模式的新手。他善於分析，注重細節，做事有條不紊。他專注於手頭的任務，即構建一個出色的應用程序。他知道他是最終對代碼負責的人。 “我不關心您想為應用程序使用什么架構，我都能完成它” |
 |
Carlos是領域專家。他通曉會議管理的所有細節。他在許多幫助人們舉辦會議的組織中工作過。他還擔任過許多不同的職務：銷售、市場營銷、會議管理和顧問。 “我想確保團隊了解這項業務的運作方式，以便我們能夠提供世界級的在線會議管理系統。” |
 |
Poe是一名專業IT人員，在雲計算中部署和運行應用程序方面是專家。他對實際解決方案有着濃厚的興趣，畢竟，他是那個在凌晨3點有問題的時候就會被呼叫的人。 “在雲中運行復雜的應用程序所面臨的挑戰和管理本地應用程序所面臨的挑戰不同。我想確保我們新的會議管理系統符合我們發布的服務水平協議(service-level agreements, SLA)。” |
 |
Beth是一位業務經理。她幫助公司規划他們的業務將如何發展。她了解公司所處的市場，公司擁有的資源，以及公司的目標。她既有戰略眼光，又對公司的日常運營感興趣。 ”公司在資源方面面臨着許多相互矛盾的需求。我想確保我們的公司能平衡這些需求，並采取一項能讓我們在中長期取得成功的商業計划。“ |
如果您對某一特定領域感興趣，可以查看與您興趣一致的專家提供的注釋。
Contoso會議管理系統
本節將按照團隊在旅程開始時的設定，介紹Contoso會議管理系統。該團隊以前從未使用過CQRS模式，因此，我們在旅程結束時交付的系統可能並不完全符合這一描述，因為:
- 我們邊學邊做的東西可能會影響我們最終的交付。
- 這是一個學習的過程，很難估計我們能在可用的時間內完成什么。
系統概述
Contoso計划建立一個在線會議管理系統，使其客戶能夠計划和管理在物理位置舉行的會議。該系統將使Contoso的客戶能夠:
- 管理會議不同類型座位的銷售。
- 創建一個會議並定義該會議的特征。
Contoso會議管理系統將是一個多租戶、雲托管的應用程序。業務客戶在創建和管理會議之前需要在系統中注冊。
會議售座
業務客戶定義會議可用的座位數量。業務客戶還可以指定會議上的活動，如研討會、招待會和高級會議，與會者必須有單獨的票。業務客戶還定義了這些活動可用的座位數量。
該系統管理座位的銷售，以確保會議和子活動沒有超額認購。該系統的這部分還將執行候補名單，以便如果其他與會者取消，他們的座位可以重新分配。
系統將要求與會者的姓名與購買的座位相關聯，以便現場系統在與會者到達會議現場時為他們打印徽章。
創建會議
業務客戶可以創建新的會議，並管理有關會議的信息，如會議名稱、描述和日期。業務客戶還可以通過發布會議，使會議在Contoso會議管理系統網站上可見，或者通過取消發布來隱藏會議。
此外，業務客戶還可以為會議定義每種座位的類型和可用數量。
Contoso還計划可以使業務客戶能夠指定會議的以下特征:
- 論文提交過程是否需要審閱。
- 什么樣的收費架構。
- 關鍵人員是哪位，例如：項目主席，活動策划者
非功能性需求
Contoso對其會議管理系統有兩個主要的非功能性需求：可擴展性和靈活性，它希望CQRS模式能夠幫助它滿足這兩個需求。
可擴展性
會議管理系統將托管在雲端。Contoso選擇雲平台的原因之一是它的可擴展性和彈性潛力。
盡管像Azure這樣的雲平台允許您通過添加(或刪除)角色實例來擴展應用程序，但是您仍然必須將應用程序設計為可擴展的。對於許多應用程序來說，讀操作的數量遠遠超過寫操作的數量。通過將應用程序的讀寫操作划分為單獨的對象，CQRS模式允許Contoso將這些操作划分為單獨的Azure角色，這些角色可以彼此獨立擴展。這意味着Contoso有機會更有效地擴展會議管理系統，並更好地利用它所使用的Azure角色實例。
靈活性
Contoso會議管理系統所處的市場競爭非常激烈，而且發展非常迅速。為了競爭，Contoso必須能夠快速有效地使會議管理系統適應市場的變化。對靈活性的這一要求可分為若干相關方面:
-
系統必須能夠不斷改進，以滿足新的需求，並對市場的變化做出反應。
Beth(業務經理)發言：
Contoso計划通過快速響應市場變化和客戶需求來競爭。Contoso必須能夠快速而無痛地改進擴展這個系統。 -
系統必須能夠同時運行多個版本的軟件，以支持正在使用來開會的客戶，以及不希望立即升級到新版本的客戶。其他客戶可能希望在軟件的新版本可用時將現有會議數據遷徙到新版本。
Poe(IT運維)發言：
這是一個巨大的挑戰：在所有客戶還在運行系統的過程中進行不停機升級。 -
Contoso希望這款軟件至少能使用五年。它必須能夠適應這段時期內的重大變化。
-
Contoso不希望系統某些部分的復雜性成為未來改變的障礙。
-
Contoso希望使用不同層次的開發人來開發系統的不同部分，簡單的任務使用便宜的開發人員，更貴和更有經驗的的開發人員用於開發系統的關鍵部分。
Gary(CQRS專家)發言：
在CQRS社區中有一些爭論，關於在實踐中，您是否可以為CQRS模式實現的不同部分使用不同的開發團隊。
即將開始CQRS之旅
下一章是我們CQRS旅程的開始。它提供了關於Contoso會議管理系統的更多信息，並描述了系統的一些高級部分。隨后的章節描述了Contoso實現會議管理系統的過程。