傳統SOA單體架構如同下面多層蛋糕一樣，雖然實現了分層架構，但是實際中人們切蛋糕時，總喜歡豎切蛋糕，這樣每個人能嚐到多層蛋糕中每一層味道。

在敏捷開發團隊中工作時，無論是業務分析師，Scrum Master，產品負責人還是開發人員，我們所有人都已經聽說過如何以及為什麼必須垂直切入使用者需求故事中。維基百科將垂直切片描述為： 

 “ ...穿過構成軟體程式碼庫結構的各層的橫截面切片。例如，一個簡單的垂直切片將包含資料訪問層，業務邏輯層和使用者介面層。

下面是我們使用此定義所看到的垂直切片圖，需求故事被垂直切入應用程式的不同層。

幾年前確實如此，當時將多個服務和UI層作為一個工件部署，並在大多數情況下是由一個團隊開發。但是，隨著微服務架構的發展以及API可以消費的渠道數量的增加，從永續性到UI層的垂直切入的故事是不可能的。

隨著微服務平臺的發展和API的增加，我們將不得不以不同的方式思考，例如分別提供蛋糕基，糖霜，鮮奶油和巧克力粉，這樣我們不但可以製造出蛋糕、還能製造出冰淇淋聖代或提供全新的甜點。

假設有一個稱為Binging的視訊流服務示例。如果要顯示視訊的平均收視率，我們會寫這個故事用例：作為Binging的使用者，我想檢視每個視訊的平均收視率，這樣我可以決定觀看哪個視訊。

這個用例故事將包括：從資料庫中獲取評分，計算平均值並將其顯示在UI上。在傳統單體架構中，通常做一個大服務實現這個用例故事，包括UI、服務邏輯和持久層，這樣服務邏輯耦合了UI的可能顯示格式等。但是，實際上我們不知道哪個服務使用者需要顯示收視率以及在UI上顯示哪種格式。

使用微服務的Binging服務的高階體系結構架構圖如下所示：

團隊的結構將複製上述架構：

在這種微服務架構下，不可能像以前單體SOA服務那樣，專門有一個服務用於顯示視訊的平均收視率了，這一個大服務被分成不同的小服務：一個Rating服務和眾多這個服務的消費者渠道服務了：

1. Rating服務：對於Rating服務的消費者客戶端可以獲得的功能：我要顯示視訊列表中的平均收視率，然後顯示給我的使用者。

2. 安卓或蘋果客戶端app的服務：這個服務是針對安卓蘋果客戶端的，這些客戶端使用者可以看到所有視訊的平均收視率，這樣他可以決定看哪個視訊。

3. 網站Web服務：這個服務針對網站使用者，使用者可以看到某個指定視訊的平均收視率，這樣能與其他視訊進行比較。

“安卓或蘋果客戶端app的服務”是“Rating服務”的消費者客戶端，自己是一種渠道服務，這兩種服務互為呼叫者和被呼叫者關係。同理，“網站Web服務”也是“Rating服務”的消費者客戶端，自己也是一種渠道服務。

這裡的Rating服務是更基礎的微服務（國內俗語：中臺服務？），這個Rating服務不同於傳統於垂直切片煙囪式的大服務，包含了UI、業務邏輯和資料庫三層的應用服務。

這裡的問題是，我們是否會增加工作量和時間來提供顯示平均收視率的功能？ 

不是，這是因為現在UI客戶端已經不同於以前單一的Web，多種UI客戶端，顯示收視率的渠道數量增加了，針對每個渠道能以不同格式顯示收視率的靈活性。

例如，安卓或蘋果app上的收視率可以與視訊列表一起顯示，但是，在Web網站上，收視率可以顯示在視訊詳細資訊頁面上。除了顯示的靈活性外，它還減少了新功能的推出時間。

此外，“Rating服務”可用於分析，報告，市場研究等。例如，我們可以回答諸如“哪些是收視率最高的視訊？”，“哪些視訊對哪些人群的評價最高？”之類的問題。和“哪些視訊在哪個國家/地區被評為高或低？”。“Rating服務”服務可以回答這些問題，而不會影響任何渠道。

Rating服務和各個渠道消費者自己的渠道服務定位不同：“Rating服務”是從資料儲存中提取所有收視率，計算平均值，併發出指定視訊或視訊列表的平均收視率。而渠道服務將呼叫“Rating服務”，並以直觀且使用者友好的格式顯示每個視訊的平均收視率。

這裡要記住的一件事是，所有POD都應瞭解並就其產品邊界達成一致。這將有助於端到端功能的優先順序劃分和規劃。當您開始從單一應用程式遷移到微服務體系結構時，這將有些困難和挑戰，但是一旦所有POD理解了各自產品的職責，它便照常營業。

 注：本文已被大幅度改寫，但中心思想未變，原文點選標題。

總結：微服務 = DDD領域服務+渠道服務！ Rating服務=DDD領域服務；安卓或蘋果或web服務=渠道服務。