CQRS之旅——旅程1(咱們的領域：Contoso會議管理系統)

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