網(wǎng)站制作實例公司網(wǎng)站建設(shè)流程
目錄
1、前言
2、軟件架構(gòu)模式的演進
3、微服務(wù)設(shè)計和拆分的困境
4、為什么 DDD適合微服務(wù)
5、DDD與微服務(wù)的關(guān)系
6、總結(jié)
1、前言
我們知道，微服務(wù)設(shè)計過程中往往會面臨邊界如何劃定的問題，不同的人會根據(jù)自己對微服務(wù)的理
解而拆分出不同的微服務(wù)，于是大家各執(zhí)一詞，誰也說服不了誰，都覺得自己很有道理。
那在實際落地過程中，見過不少項目在面臨這種微服務(wù)設(shè)計困惑時，是靠拍腦袋硬完成的，上線后
運維的壓力就可想而知了。那是否有合適的理論或設(shè)計方法來指導(dǎo)微服務(wù)設(shè)計呢？有的，就是
領(lǐng)域驅(qū)動設(shè)計（DDD）。
2、軟件架構(gòu)模式的演進
我們知道，這些年來隨著設(shè)備和新技術(shù)的發(fā)展，軟件的架構(gòu)模式發(fā)生了很大的變化。
軟件架構(gòu)模式大體來說經(jīng)歷了從單機、集中式到分布式微服務(wù)架構(gòu)三個階段的演進。隨著分布式技
術(shù)的快速興起，我們已經(jīng)進入到了微服務(wù)架構(gòu)時代。
我們先來分析一下，軟件架構(gòu)模式演進的三個階段。
第一階段是單機架構(gòu)
采用面向過程的設(shè)計方法，系統(tǒng)包括客戶端 UI 層和數(shù)據(jù)庫兩層，采用 C/S 架構(gòu)模式，整個系統(tǒng)圍
繞數(shù)據(jù)庫驅(qū)動設(shè)計和開發(fā)，并且總是從設(shè)計數(shù)據(jù)庫和字段開始。
第二階段是集中式架構(gòu)
采用面向?qū)ο蟮脑O(shè)計方法，系統(tǒng)包括業(yè)務(wù)接入層、業(yè)務(wù)邏輯層和數(shù)據(jù)庫層，采用經(jīng)典的三層架構(gòu)，
也有部分應(yīng)用采用傳統(tǒng)的 SOA 架構(gòu)。這種架構(gòu)容易使系統(tǒng)變得臃腫，可擴展性和彈性伸縮性差。
第三階段是分布式微服務(wù)架構(gòu)
隨著微服務(wù)架構(gòu)理念的提出，集中式架構(gòu)正向分布式微服務(wù)架構(gòu)演進。微服務(wù)架構(gòu)可以很好地實現(xiàn)
應(yīng)用之間的解耦，解決單體應(yīng)用擴展性和彈性伸縮能力不足的問題。
我們知道，在單機和集中式架構(gòu)時代，系統(tǒng)分析、設(shè)計和開發(fā)往往是獨立、分階段割裂進行的。
比如，在系統(tǒng)建設(shè)過程中，我們經(jīng)常會看到這樣的情形：A 負責(zé)提出需求，B 負責(zé)需求分析，C 負
責(zé)系統(tǒng)設(shè)計，D負責(zé)代碼實現(xiàn)，這樣的流程很長，經(jīng)手的人也很多，很容易導(dǎo)致信息丟失。最后，
就很容易導(dǎo)致需求、設(shè)計與代碼實現(xiàn)的不一致，往往到了軟件上線后，我們才發(fā)現(xiàn)很多功能并不是
自己想要的，或者做出來的功能跟自己提出的需求偏差太大。
而且在單機和集中式架構(gòu)這兩種模式下，軟件無法快速響應(yīng)需求和業(yè)務(wù)的迅速變化，最終錯失發(fā)展
良機。此時，分布式微服務(wù)的出現(xiàn)就有點恰逢其時的意思了。
3、微服務(wù)設(shè)計和拆分的困境
那進入微服務(wù)架構(gòu)時代以后，微服務(wù)確實也解決了原來采用集中式架構(gòu)的單體應(yīng)用的很多問題，比
如擴展性、彈性伸縮能力、小規(guī)模團隊的敏捷開發(fā)等等。
但在看到這些好處的同時，微服務(wù)實踐過程中也產(chǎn)生了不少的爭論和疑惑：微服務(wù)的粒度應(yīng)該多大
呀？微服務(wù)到底應(yīng)該如何拆分和設(shè)計呢？微服務(wù)的邊界應(yīng)該在哪里？
可以說，很久以來都沒有一套系統(tǒng)的理論和方法可以指導(dǎo)微服務(wù)的拆分，包括微服務(wù)架構(gòu)模式的提
出者 Martin Fowler 在提出微服務(wù)架構(gòu)的時候，也沒有告訴我們究竟應(yīng)該如何拆分微服務(wù)。
于是，在這段較長的時間里，就有不少人對微服務(wù)的理解產(chǎn)生了一些曲解。有人認(rèn)為：“微服務(wù)很
簡單，不過就是把原來一個單體包拆分為多個部署包，或者將原來的單體應(yīng)用架構(gòu)替換為一套支持
微服務(wù)架構(gòu)的技術(shù)框架，就算是微服務(wù)了。” 還有人說：“微服務(wù)嘛，就是要微要小，拆得越小效
果越好?！?/strong>
但我想這兩年，你在技術(shù)圈中一定聽說過一些項目因為前期微服務(wù)拆分過度，導(dǎo)致項目復(fù)雜度過
高，無法上線和運維。
綜合來看，我認(rèn)為微服務(wù)拆分困境產(chǎn)生的根本原因就是不知道業(yè)務(wù)或者微服務(wù)的邊界到底在什么地
方。換句話說，確定了業(yè)務(wù)邊界和應(yīng)用邊界，這個困境也就迎刃而解了。
那如何確定，是否有相關(guān)理論或知識體系支持呢？在回答這些問題之前，我們先來了解一下領(lǐng)域驅(qū)
動設(shè)計與微服務(wù)的前世今生。
2004 年埃里克·埃文斯（Eric Evans）發(fā)表了《領(lǐng)域驅(qū)動設(shè)計》（Domain-Driven Design–Tackling
Complexity in the Heart of Software）這本書，從此領(lǐng)域驅(qū)動設(shè)計（DomainDriven Design，簡稱
DDD）誕生。DDD核心思想是通過領(lǐng)域驅(qū)動設(shè)計方法定義領(lǐng)域模型，從而確定業(yè)務(wù)和應(yīng)用邊界，
保證業(yè)務(wù)模型與代碼模型的一致性。
但 DDD提出后在軟件開發(fā)領(lǐng)域一直都是“雷聲大，雨點小”！直到 Martin Fowler 提出微服務(wù)架構(gòu)，
DDD才真正迎來了自己的時代。
有些熟悉 DDD設(shè)計方法的軟件工程師在進行微服務(wù)設(shè)計時，發(fā)現(xiàn)可以利用 DDD設(shè)計方法來建立領(lǐng)
域模型，劃分領(lǐng)域邊界，再根據(jù)這些領(lǐng)域邊界從業(yè)務(wù)視角來劃分微服務(wù)邊界。而按照 DDD方法設(shè)
計出的微服務(wù)的業(yè)務(wù)和應(yīng)用邊界都非常合理，可以很好地實現(xiàn)微服務(wù)內(nèi)部和外部的“高內(nèi)聚、低耦
合”。于是越來越多的人開始把 DDD作為微服務(wù)設(shè)計的指導(dǎo)思想。
現(xiàn)在，很多大型互聯(lián)網(wǎng)企業(yè)已經(jīng)將 DDD設(shè)計方法作為微服務(wù)的主流設(shè)計方法了。DDD也從過去“雷
聲大，雨點小”，開始真正火爆起來。
4、為什么 DDD適合微服務(wù)
DDD 是一種處理高度復(fù)雜領(lǐng)域的設(shè)計思想，它試圖分離技術(shù)實現(xiàn)的復(fù)雜性，并圍繞業(yè)務(wù)概念構(gòu)建
領(lǐng)域模型來控制業(yè)務(wù)的復(fù)雜性，以解決軟件難以理解，難以演進的問題。DDD不是架構(gòu)，而是一
種架構(gòu)設(shè)計方法論，它通過邊界劃分將復(fù)雜業(yè)務(wù)領(lǐng)域簡單化，幫我們設(shè)計出清晰的領(lǐng)域和應(yīng)用邊
界，可以很容易地實現(xiàn)架構(gòu)演進。
DDD包括戰(zhàn)略設(shè)計和戰(zhàn)術(shù)設(shè)計兩部分。
戰(zhàn)略設(shè)計主要從業(yè)務(wù)視角出發(fā)，建立業(yè)務(wù)領(lǐng)域模型，劃分領(lǐng)域邊界，建立通用語言的限界上下文，
限界上下文可以作為微服務(wù)設(shè)計的參考邊界。
戰(zhàn)術(shù)設(shè)計則從技術(shù)視角出發(fā)，側(cè)重于領(lǐng)域模型的技術(shù)實現(xiàn)，完成軟件開發(fā)和落地，包括：聚合根、
實體、值對象、領(lǐng)域服務(wù)、應(yīng)用服務(wù)和資源庫等代碼邏輯的設(shè)計和實現(xiàn)。
我們來看看 DDD是如何進行戰(zhàn)略設(shè)計的。
DDD戰(zhàn)略設(shè)計會建立領(lǐng)域模型，領(lǐng)域模型可以用于指導(dǎo)微服務(wù)的設(shè)計和拆分。事件風(fēng)暴是建立領(lǐng)
域模型的主要方法，它是一個從發(fā)散到收斂的過程。它通常采用用例分析、場景分析和用戶旅程分
析，盡可能全面不遺漏地分解業(yè)務(wù)領(lǐng)域，并梳理領(lǐng)域?qū)ο笾g的關(guān)系，這是一個發(fā)散的過程。事件
風(fēng)暴過程會產(chǎn)生很多的實體、命令、事件等領(lǐng)域?qū)ο?#xff0c;我們將這些領(lǐng)域?qū)ο髲牟煌木S度進行聚
類，形成如聚合、限界上下文等邊界，建立領(lǐng)域模型，這就是一個收斂的過程。
我們可以用三步來劃定領(lǐng)域模型和微服務(wù)的邊界。
第一步：在事件風(fēng)暴中梳理業(yè)務(wù)過程中的用戶操作、事件以及外部依賴關(guān)系等，根據(jù)這些要素梳理
出領(lǐng)域?qū)嶓w等領(lǐng)域?qū)ο蟆?/p>
第二步：根據(jù)領(lǐng)域?qū)嶓w之間的業(yè)務(wù)關(guān)聯(lián)性，將業(yè)務(wù)緊密相關(guān)的實體進行組合形成聚合，同時確定聚
合中的聚合根、值對象和實體。在這個圖里，聚合之間的邊界是第一層邊界，它們在同一個微服務(wù)
實例中運行，這個邊界是邏輯邊界，所以用虛線表示。
第三步：根據(jù)業(yè)務(wù)及語義邊界等因素，將一個或者多個聚合劃定在一個限界上下文內(nèi)，形成領(lǐng)域模
型。在這個圖里，限界上下文之間的邊界是第二層邊界，這一層邊界可能就是未來微服務(wù)的邊界，
不同限界上下文內(nèi)的領(lǐng)域邏輯被隔離在不同的微服務(wù)實例中運行，物理上相互隔離，所以是物理邊
界，邊界之間用實線來表示。
有了這兩層邊界，微服務(wù)的設(shè)計就不是什么難事了。
在戰(zhàn)略設(shè)計中我們建立了領(lǐng)域模型，劃定了業(yè)務(wù)領(lǐng)域的邊界，建立了通用語言和限界上下文，確定
了領(lǐng)域模型中各個領(lǐng)域?qū)ο蟮年P(guān)系。到這兒，業(yè)務(wù)端領(lǐng)域模型的設(shè)計工作基本就完成了，這個過程
同時也基本確定了應(yīng)用端的微服務(wù)邊界。
在從業(yè)務(wù)模型向微服務(wù)落地的過程中，也就是從戰(zhàn)略設(shè)計向戰(zhàn)術(shù)設(shè)計的實施過程中，我們會將領(lǐng)域
模型中的領(lǐng)域?qū)ο笈c代碼模型中的代碼對象建立映射關(guān)系，將業(yè)務(wù)架構(gòu)和系統(tǒng)架構(gòu)進行綁定。當(dāng)我
們?nèi)ロ憫?yīng)業(yè)務(wù)變化調(diào)整業(yè)務(wù)架構(gòu)和領(lǐng)域模型時，系統(tǒng)架構(gòu)也會同時發(fā)生調(diào)整，并同步建立新的映射
關(guān)系。
5、DDD與微服務(wù)的關(guān)系
有了上面的講解，現(xiàn)在我們再次總結(jié)下 DDD與微服務(wù)的關(guān)系。
DDD是一種架構(gòu)設(shè)計方法，微服務(wù)是一種架構(gòu)風(fēng)格，兩者從本質(zhì)上都是為了追求高響應(yīng)力，而從
業(yè)務(wù)視角去分離應(yīng)用系統(tǒng)建設(shè)復(fù)雜度的手段。兩者都強調(diào)從業(yè)務(wù)出發(fā)，其核心要義是強調(diào)根據(jù)業(yè)務(wù)
發(fā)展，合理劃分領(lǐng)域邊界，持續(xù)調(diào)整現(xiàn)有架構(gòu)，優(yōu)化現(xiàn)有代碼，以保持架構(gòu)和代碼的生命力，也就
是我們常說的演進式架構(gòu)。
DDD主要關(guān)注：從業(yè)務(wù)領(lǐng)域視角劃分領(lǐng)域邊界，構(gòu)建通用語言進行高效溝通，通過業(yè)務(wù)抽象，建
立領(lǐng)域模型，維持業(yè)務(wù)和代碼的邏輯一致性。
微服務(wù)主要關(guān)注：運行時的進程間通信、容錯和故障隔離，實現(xiàn)去中心化數(shù)據(jù)管理和去中心化服務(wù)
治理，關(guān)注微服務(wù)的獨立開發(fā)、測試、構(gòu)建和部署。
6、總結(jié)
今天我們主要學(xué)習(xí)微服務(wù)設(shè)計和拆分的難題。通過DDD戰(zhàn)略設(shè)計可以建立領(lǐng)域模型，劃定領(lǐng)域邊
界，解決微服務(wù)設(shè)計過程中，邊界難以劃定的難題。如果你的業(yè)務(wù)焦點在領(lǐng)域和領(lǐng)域邏輯，那么你
就可以選擇DDD作為微服務(wù)的設(shè)計方法！
更關(guān)鍵的一點是，DDD不僅可以用于微服務(wù)設(shè)計，還可以很好地應(yīng)用于企業(yè)中臺的設(shè)計。
如果你的企業(yè)正在做中臺轉(zhuǎn)型，DDD將會是一把利器，它可以幫你建立一個非常好的企業(yè)級中臺
業(yè)務(wù)模型。有關(guān)這點你還會在后面的文章中見到詳解。
除此之外，DDD戰(zhàn)術(shù)設(shè)計對設(shè)計和開發(fā)人員的要求相對較高，實現(xiàn)起來相對復(fù)雜。不同企業(yè)的研
發(fā)管理能力和個人開發(fā)水平可能會存在差異。尤其對于傳統(tǒng)企業(yè)而言，在戰(zhàn)術(shù)設(shè)計落地的過程中，
可能會存在一定挑戰(zhàn)和困難，我建議你和你的公司如果有這方面的想法，就一定要謹(jǐn)慎評估自己的
能力，選擇最合適的方法落地DDD。
總體來說，DDD可以給你帶來以下收獲：
-
DDD是一套完整而系統(tǒng)的設(shè)計方法，它能帶給你從戰(zhàn)略設(shè)計到戰(zhàn)術(shù)設(shè)計的標(biāo)準(zhǔn)設(shè)計過程，使得你的設(shè)計思路能夠更加清晰，設(shè)計過程更加規(guī)范。
-
DDD善于處理與領(lǐng)域相關(guān)的擁有高復(fù)雜度業(yè)務(wù)的產(chǎn)品開發(fā)，通過它可以建立一個核心而穩(wěn)定的領(lǐng)域模型，有利于領(lǐng)域知識的傳遞與傳承。
-
DDD強調(diào)團隊與領(lǐng)域?qū)＜业暮献?/strong>，能夠幫助你的團隊建立一個溝通良好的氛圍，構(gòu)建一致的架構(gòu)體系。
-
DDD的設(shè)計思想、原則與模式有助于提高你的架構(gòu)設(shè)計能力。
-
無論是在新項目中設(shè)計微服務(wù)，還是將系統(tǒng)從單體架構(gòu)演進到微服務(wù)，都可以遵循DDD的架構(gòu)原則。
-
DDD不僅適用于微服務(wù)，也適用于傳統(tǒng)的單體應(yīng)用。