旅程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實現會議管理系統的過程。