• <tbody id="24cmm"></tbody>
  • 您的位置:知識庫 ? 軟件設計

    領域驅動設計在互聯網業務開發中的實踐

    作者: 文彬 子維  來源: tech.meituan  發布時間: 2018-01-18 21:06  閱讀: 11119 次  推薦: 33   原文鏈接   [收藏]  

      前言

      至少30年以前,一些軟件設計人員就已經意識到領域建模和設計的重要性,并形成一種思潮,Eric Evans將其定義為領域驅動設計(Domain-Driven Design,簡稱DDD)。在互聯網開發“小步快跑,迭代試錯”的大環境下,DDD似乎是一種比較“古老而緩慢”的思想。然而,由于互聯網公司也逐漸深入實體經濟,業務日益復雜,我們在開發中也越來越多地遇到傳統行業軟件開發中所面臨的問題。本文就先來講一下這些問題,然后再嘗試在實踐中用DDD的思想來解決這些問題。

      問題

      過度耦合

      業務初期,我們的功能大都非常簡單,普通的CRUD就能滿足,此時系統是清晰的。隨著迭代的不斷演化,業務邏輯變得越來越復雜,我們的系統也越來越冗雜。模塊彼此關聯,誰都很難說清模塊的具體功能意圖是啥。修改一個功能時,往往光回溯該功能需要的修改點就需要很長時間,更別提修改帶來的不可預知的影響面。

      下圖是一個常見的系統耦合病例。

      訂單服務接口中提供了查詢、創建訂單相關的接口,也提供了訂單評價、支付、保險的接口。同時我們的表也是一個訂單大表,包含了非常多字段。在我們維護代碼時,牽一發而動全身,很可能只是想改下評價相關的功能,卻影響到了創單核心路徑。雖然我們可以通過測試保證功能完備性,但當我們在訂單領域有大量需求同時并行開發時,改動重疊、惡性循環、疲于奔命修改各種問題。

      上述問題,歸根到底在于系統架構不清晰,劃分出來的模塊內聚度低、高耦合。

      有一種解決方案,按照演進式設計的理論,讓系統的設計隨著系統實現的增長而增長。我們不需要作提前設計,就讓系統伴隨業務成長而演進。這當然是可行的,敏捷實踐中的重構、測試驅動設計及持續集成可以對付各種混亂問題。重構——保持行為不變的代碼改善清除了不協調的局部設計,測試驅動設計確保對系統的更改不會導致系統丟失或破壞現有功能,持續集成則為團隊提供了同一代碼庫。

      在這三種實踐中,重構是克服演進式設計中大雜燴問題的主力,通過在單獨的類及方法級別上做一系列小步重構來完成。我們可以很容易重構出一個獨立的類來放某些通用的邏輯,但是你會發現你很難給它一個業務上的含義,只能給予一個技術維度描繪的含義。這會帶來什么問題呢?新同學并不總是知道對通用邏輯的改動或獲取來自該類。顯然,制定項目規范并不是好的idea。我們又聞到了代碼即將腐敗的味道。

      事實上,你可能意識到問題之所在。在解決現實問題時,我們會將問題映射到腦海中的概念模型,在模型中解決問題,再將解決方案轉換為實際的代碼。上述問題在于我們解決了設計到代碼之間的重構,但提煉出來的設計模型,并不具有實際的業務含義,這就導致在開發新需求時,其他同學并不能很自然地將業務問題映射到該設計模型。設計似乎變成了重構者的自娛自樂,代碼繼續腐敗,重新重構……無休止的循環。

      用DDD則可以很好地解決領域模型到設計模型的同步、演化,最后再將反映了領域的設計模型轉為實際的代碼。

      注:模型是我們解決實際問題所抽象出來的概念模型,領域模型則表達與業務相關的事實;設計模型則描述了所要構建的系統。

      貧血癥和失憶癥

    貧血領域對象

    貧血領域對象(Anemic Domain Object)是指僅用作數據載體,而沒有行為和動作的領域對象。

      在我們習慣了J2EE的開發模式后,Action/Service/DAO這種分層模式,會很自然地寫出過程式代碼,而學到的很多關于OO理論的也毫無用武之地。使用這種開發方式,對象只是數據的載體,沒有行為。以數據為中心,以數據庫ER設計作驅動。分層架構在這種開發模式下,可以理解為是對數據移動、處理和實現的過程。

      以筆者最近開發的系統抽獎平臺為例:

    • 場景需求

      獎池里配置了很多獎項,我們需要按運營預先配置的概率抽中一個獎項。
      實現非常簡單,生成一個隨機數,匹配符合該隨機數生成概率的獎項即可。

    • 貧血模型實現方案

      先設計獎池和獎項的庫表配置。

    • 設計AwardPool和Award兩個對象,只有簡單的get和set屬性的方法
    class AwardPool {
        int awardPoolId;
        List<Award> awards;
        public List<Award> getAwards() {
            return awards;
        }
    
        public void setAwards(List<Award> awards) {
            this.awards = awards;
        }
        ......
    }
    
    class Award {
       int awardId;
       int probability;//概率
    
       ......
    }
    • Service代碼實現

      設計一個LotteryService,在其中的drawLottery()方法寫服務邏輯

    AwardPool awardPool = awardPoolDao.getAwardPool(poolId);//sql查詢,將數據映射到AwardPool對象
    for (Award award : awardPool.getAwards()) {
       //尋找到符合award.getProbability()概率的award
    }
    • 按照我們通常思路實現,可以發現:在業務領域里非常重要的抽獎,我的業務邏輯都是寫在Service中的,Award充其量只是個數據載體,沒有任何行為。簡單的業務系統采用這種貧血模型和過程化設計是沒有問題的,但在業務邏輯復雜了,業務邏輯、狀態會散落到在大量方法中,原本的代碼意圖會漸漸不明確,我們將這種情況稱為由貧血癥引起的失憶癥。

      更好的是采用領域模型的開發方式,將數據和行為封裝在一起,并與現實世界中的業務對象相映射。各類具備明確的職責劃分,將領域邏輯分散到領域對象中。繼續舉我們上述抽獎的例子,使用概率選擇對應的獎品就應當放到AwardPool類中。

      為什么選擇DDD

      軟件系統復雜性應對

      解決復雜和大規模軟件的武器可以被粗略地歸為三類:抽象、分治和知識。

      分治 把問題空間分割為規模更小且易于處理的若干子問題。分割后的問題需要足夠小,以便一個人單槍匹馬就能夠解決他們;其次,必須考慮如何將分割后的各個部分裝配為整體。分割得越合理越易于理解,在裝配成整體時,所需跟蹤的細節也就越少。即更容易設計各部分的協作方式。評判什么是分治得好,即高內聚低耦合。

      抽象 使用抽象能夠精簡問題空間,而且問題越小越容易理解。舉個例子,從北京到上海出差,可以先理解為使用交通工具前往,但不需要一開始就想清楚到底是高鐵還是飛機,以及乘坐它們需要注意什么。

      知識 顧名思義,DDD可以認為是知識的一種。

      DDD提供了這樣的知識手段,讓我們知道如何抽象出限界上下文以及如何去分治。

      與微服務架構相得益彰

      微服務架構眾所周知,此處不做贅述。我們創建微服務時,需要創建一個高內聚、低耦合的微服務。而DDD中的限界上下文則完美匹配微服務要求,可以將該限界上下文理解為一個微服務進程。

      上述是從更直觀的角度來描述兩者的相似處。

      在系統復雜之后,我們都需要用分治來拆解問題。一般有兩種方式,技術維度和業務維度。技術維度是類似MVC這樣,業務維度則是指按業務領域來劃分系統。

      微服務架構更強調從業務維度去做分治來應對系統復雜度,而DDD也是同樣的著重業務視角。

      如果兩者在追求的目標(業務維度)達到了上下文的統一,那么在具體做法上有什么聯系和不同呢?

      我們將架構設計活動精簡為以下三個層面:

    • 業務架構——根據業務需求設計業務模塊及其關系
    • 系統架構——設計系統和子系統的模塊
    • 技術架構——決定采用的技術及框架

      以上三種活動在實際開發中是有先后順序的,但不一定孰先孰后。在我們解決常規套路問題時,我們會很自然地往熟悉的分層架構套(先確定系統架構),或者用PHP開發很快(先確定技術架構),在業務不復雜時,這樣是合理的。

      跳過業務架構設計出來的架構關注點不在業務響應上,可能就是個大泥球,在面臨需求迭代或響應市場變化時就很痛苦。

      DDD的核心訴求就是將業務架構映射到系統架構上,在響應業務變化調整業務架構時,也隨之變化系統架構。而微服務追求業務層面的復用,設計出來的系統架構和業務一致;在技術架構上則系統模塊之間充分解耦,可以自由地選擇合適的技術架構,去中心化地治理技術和數據。

      可以參見下圖來更好地理解雙方之間的協作關系:

      如何實踐DDD

      我們將通過上文提到的抽獎平臺,來詳細介紹我們如何通過DDD來解構一個中型的基于微服務架構的系統,從而做到系統的高內聚、低耦合。

      首先看下抽獎系統的大致需求:

    運營——可以配置一個抽獎活動,該活動面向一個特定的用戶群體,并針對一個用戶群體發放一批不同類型的獎品(優惠券,激活碼,實物獎品等)。

    用戶——通過活動頁面參與不同類型的抽獎活動。

      設計領域模型的一般步驟如下:

    1. 根據需求劃分出初步的領域和限界上下文,以及上下文之間的關系;
    2. 進一步分析每個上下文內部,識別出哪些是實體,哪些是值對象;
    3. 對實體、值對象進行關聯和聚合,劃分出聚合的范疇和聚合根;
    4. 為聚合根設計倉儲,并思考實體或值對象的創建方式;
    5. 在工程中實踐領域模型,并在實踐中檢驗模型的合理性,倒推模型中不足的地方并重構。

      戰略建模

      戰略和戰術設計是站在DDD的角度進行劃分。戰略設計側重于高層次、宏觀上去劃分和集成限界上下文,而戰術設計則關注更具體使用建模工具來細化上下文。

      領域

      現實世界中,領域包含了問題域和解系統。一般認為軟件是對現實世界的部分模擬。在DDD中,解系統可以映射為一個個限界上下文,限界上下文就是軟件對于問題域的一個特定的、有限的解決方案。

      限界上下文

    一個由顯式邊界限定的特定職責。領域模型便存在于這個邊界之內。在邊界內,每一個模型概念,包括它的屬性和操作,都具有特殊的含義。

      一個給定的業務領域會包含多個限界上下文,想與一個限界上下文溝通,則需要通過顯式邊界進行通信。系統通過確定的限界上下文來進行解耦,而每一個上下文內部緊密組織,職責明確,具有較高的內聚性。

      一個很形象的隱喻:細胞質所以能夠存在,是因為細胞膜限定了什么在細胞內,什么在細胞外,并且確定了什么物質可以通過細胞膜。

      劃分限界上下文

      劃分限界上下文,不管是Eric Evans還是Vaughn Vernon,在他們的大作里都沒有怎么提及。

      顯然我們不應該按技術架構或者開發任務來創建限界上下文,應該按照語義的邊界來考慮。

      我們的實踐是,考慮產品所講的通用語言,從中提取一些術語稱之為概念對象,尋找對象之間的聯系;或者從需求里提取一些動詞,觀察動詞和對象之間的關系;我們將緊耦合的各自圈在一起,觀察他們內在的聯系,從而形成對應的限界上下文。形成之后,我們可以嘗試用語言來描述下限上下文的職責,看它是否清晰、準確、簡潔和完整。簡言之,限界上下文應該從需求出發,按領域劃分。

      前文提到,我們的用戶劃分為運營和用戶。其中,運營對抽獎活動的配置十分復雜但相對低頻。用戶對這些抽獎活動配置的使用是高頻次且無感知的。根據這樣的業務特點,我們首先將抽獎平臺劃分為C端抽獎和M端抽獎管理平臺兩個子域,讓兩者完全解耦。

      在確認了M端領域和C端的限界上下文后,我們再對各自上下文內部進行限界上下文的劃分。下面我們用C端進行舉例。

      產品的需求概述如下:

    1. 抽獎活動有活動限制,例如用戶的抽獎次數限制,抽獎的開始和結束的時間等;
    2. 一個抽獎活動包含多個獎品,可以針對一個或多個用戶群體;
    3. 獎品有自身的獎品配置,例如庫存量,被抽中的概率等,最多被一個用戶抽中的次數等等;
    4. 用戶群體有多種區別方式,如按照用戶所在城市區分,按照新老客區分等;
    5. 活動具有風控配置,能夠限制用戶參與抽獎的頻率。

      根據產品的需求,我們提取了一些關鍵性的概念作為子域,形成我們的限界上下文。

      首先,抽獎上下文作為整個領域的核心,承擔著用戶抽獎的核心業務,抽獎中包含了獎品和用戶群體的概念。

    • 在設計初期,我們曾經考慮劃分出抽獎和發獎兩個領域,前者負責選獎,后者負責將選中的獎品發放出去。但在實際開發過程中,我們發現這兩部分的邏輯緊密連接,難以拆分。并且單純的發獎邏輯足夠簡單,僅僅是調用第三方服務進行發獎,不足以獨立出來成為一個領域。

      對于活動的限制,我們定義了活動準入的通用語言,將活動開始/結束時間,活動可參與次數等限制條件都收攏到活動準入上下文中。

      對于抽獎的獎品庫存量,由于庫存的行為與獎品本身相對解耦,庫存關注點更多是庫存內容的核銷,且庫存本身具備通用性,可以被獎品之外的內容使用,因此我們定義了獨立的庫存上下文。

      由于C端存在一些刷單行為,我們根據產品需求定義了風控上下文,用于對活動進行風控。

      最后,活動準入、風控、抽獎等領域都涉及到一些次數的限制,因此我們定義了計數上下文。

      可以看到,通過DDD的限界上下文劃分,我們界定出抽獎、活動準入、風控、計數、庫存等五個上下文,每個上下文在系統中都高度內聚。

      上下文映射圖

      在進行上下文劃分之后,我們還需要進一步梳理上下文之間的關系。

    康威(梅爾·康威)定律

    任何組織在設計一套系統(廣義概念上的系統)時,所交付的設計方案在結構上都與該組織的溝通結構保持一致。

      康威定律告訴我們,系統結構應盡量的與組織結構保持一致。這里,我們認為團隊結構(無論是內部組織還是團隊間組織)就是組織結構,限界上下文就是系統的業務結構。因此,團隊結構應該和限界上下文保持一致。

      梳理清楚上下文之間的關系,從團隊內部的關系來看,有如下好處:

    1. 任務更好拆分,一個開發人員可以全身心的投入到相關的一個單獨的上下文中;
    2. 溝通更加順暢,一個上下文可以明確自己對其他上下文的依賴關系,從而使得團隊內開發直接更好的對接。

      從團隊間的關系來看,明確的上下文關系能夠帶來如下幫助:

    1. 每個團隊在它的上下文中能夠更加明確自己領域內的概念,因為上下文是領域的解系統;
    2. 對于限界上下文之間發生交互,團隊與上下文的一致性,能夠保證我們明確對接的團隊和依賴的上下游。

    限界上下文之間的映射關系

    • 合作關系(Partnership):兩個上下文緊密合作的關系,一榮俱榮,一損俱損。
    • 共享內核(Shared Kernel):兩個上下文依賴部分共享的模型。
    • 客戶方-供應方開發(Customer-Supplier Development):上下文之間有組織的上下游依賴。
    • 遵奉者(Conformist):下游上下文只能盲目依賴上游上下文。
    • 防腐層(Anticorruption Layer):一個上下文通過一些適配和轉換與另一個上下文交互。
    • 開放主機服務(Open Host Service):定義一種協議來讓其他上下文來對本上下文進行訪問。
    • 發布語言(Published Language):通常與OHS一起使用,用于定義開放主機的協議。
    • 大泥球(Big Ball of Mud):混雜在一起的上下文關系,邊界不清晰。
    • 另謀他路(Separate Way):兩個完全沒有任何聯系的上下文。

      上文定義了上下文映射間的關系,經過我們的反復斟酌,抽獎平臺上下文的映射關系圖如下:

      由于抽獎,風控,活動準入,庫存,計數五個上下文都處在抽獎領域的內部,所以它們之間符合“一榮俱榮,一損俱損”的合作關系(PartnerShip,簡稱PS)。

      同時,抽獎上下文在進行發券動作時,會依賴券碼、平臺券、外賣券三個上下文。抽獎上下文通過防腐層(Anticorruption Layer,ACL)對三個上下文進行了隔離,而三個券上下文通過開放主機服務(Open Host Service)作為發布語言(Published Language)對抽獎上下文提供訪問機制。

      通過上下文映射關系,我們明確的限制了限界上下文的耦合性,即在抽獎平臺中,無論是上下文內部交互(合作關系)還是與外部上下文交互(防腐層),耦合度都限定在數據耦合(Data Coupling)的層級。

      戰術建模——細化上下文

      梳理清楚上下文之間的關系后,我們需要從戰術層面上剖析上下文內部的組織關系。首先看下DDD中的一些定義。

    實體

    當一個對象由其標識(而不是屬性)區分時,這種對象稱為實體(Entity)。

    例:最簡單的,公安系統的身份信息錄入,對于人的模擬,即認為是實體,因為每個人是獨一無二的,且其具有唯一標識(如公安系統分發的身份證號碼)。

      在實踐上建議將屬性的驗證放到實體中。

    值對象

    當一個對象用于對事務進行描述而沒有唯一標識時,它被稱作值對象(Value Object)。

    例:比如顏色信息,我們只需要知道{"name":"黑色","css":"#000000"}這樣的值信息就能夠滿足要求了,這避免了我們對標識追蹤帶來的系統復雜性。

      值對象很重要,在習慣了使用數據庫的數據建模后,很容易將所有對象看作實體。使用值對象,可以更好地做系統優化、精簡設計。

      它具有不變性、相等性和可替換性。

      在實踐中,需要保證值對象創建后就不能被修改,即不允許外部再修改其屬性。在不同上下文集成時,會出現模型概念的公用,如商品模型會存在于電商的各個上下文中。在訂單上下文中如果你只關注下單時商品信息快照,那么將商品對象視為值對象是很好的選擇。

    聚合根

    Aggregate(聚合)是一組相關對象的集合,作為一個整體被外界訪問,聚合根(Aggregate Root)是這個聚合的根節點。

      聚合是一個非常重要的概念,核心領域往往都需要用聚合來表達。其次,聚合在技術上有非常高的價值,可以指導詳細設計。

      聚合由根實體,值對象和實體組成。

      如何創建好的聚合?

    • 邊界內的內容具有一致性:在一個事務中只修改一個聚合實例。如果你發現邊界內很難接受強一致,不管是出于性能或產品需求的考慮,應該考慮剝離出獨立的聚合,采用最終一致的方式。
    • 設計小聚合:大部分的聚合都可以只包含根實體,而無需包含其他實體。即使一定要包含,可以考慮將其創建為值對象。
    • 通過唯一標識來引用其他聚合或實體:當存在對象之間的關聯時,建議引用其唯一標識而非引用其整體對象。如果是外部上下文中的實體,引用其唯一標識或將需要的屬性構造值對象。
      如果聚合創建復雜,推薦使用工廠方法來屏蔽內部復雜的創建邏輯。

      聚合內部多個組成對象的關系可以用來指導數據庫創建,但不可避免存在一定的抗阻。如聚合中存在List<值對象>,那么在數據庫中建立1:N的關聯需要將值對象單獨建表,此時是有id的,建議不要將該id暴露到資源庫外部,對外隱蔽。

    領域服務

    一些重要的領域行為或操作,可以歸類為領域服務。它既不是實體,也不是值對象的范疇。

      當我們采用了微服務架構風格,一切領域邏輯的對外暴露均需要通過領域服務來進行。如原本由聚合根暴露的業務邏輯也需要依托于領域服務。

    領域事件

    領域事件是對領域內發生的活動進行的建模。

      抽獎平臺的核心上下文是抽獎上下文,接下來介紹下我們對抽獎上下文的建模。

      在抽獎上下文中,我們通過抽獎(DrawLottery)這個聚合根來控制抽獎行為,可以看到,一個抽獎包括了抽獎ID(LotteryId)以及多個獎池(AwardPool),而一個獎池針對一個特定的用戶群體(UserGroup)設置了多個獎品(Award)。

      另外,在抽獎領域中,我們還會使用抽獎結果(SendResult)作為輸出信息,使用用戶領獎記錄(UserLotteryLog)作為領獎憑據和存根。

      謹慎使用值對象

      在實踐中,我們發現雖然一些領域對象符合值對象的概念,但是隨著業務的變動,很多原有的定義會發生變更,值對象可能需要在業務意義具有唯一標識,而對這類值對象的重構往往需要較高成本。因此在特定的情況下,我們也要根據實際情況來權衡領域對象的選型。

      DDD工程實現

      在對上下文進行細化后,我們開始在工程中真正落地DDD。

      模塊

      模塊(Module)是DDD中明確提到的一種控制限界上下文的手段,在我們的工程中,一般盡量用一個模塊來表示一個領域的限界上下文。

      如代碼中所示,一般的工程中包的組織方式為{com.公司名.組織架構.業務.上下文.*},這樣的組織結構能夠明確的將一個上下文限定在包的內部。

    import com.company.team.bussiness.lottery.*;//抽獎上下文
    import com.company.team.bussiness.riskcontrol.*;//風控上下文
    import com.company.team.bussiness.counter.*;//計數上下文
    import com.company.team.bussiness.condition.*;//活動準入上下文
    import com.company.team.bussiness.stock.*;//庫存上下文
    代碼演示1 模塊的組織

      對于模塊內的組織結構,一般情況下我們是按照領域對象、領域服務、領域資源庫、防腐層等組織方式定義的。

    import com.company.team.bussiness.lottery.domain.valobj.*;//領域對象-值對象
    import com.company.team.bussiness.lottery.domain.entity.*;//領域對象-實體
    import com.company.team.bussiness.lottery.domain.aggregate.*;//領域對象-聚合根
    import com.company.team.bussiness.lottery.service.*;//領域服務
    import com.company.team.bussiness.lottery.repo.*;//領域資源庫
    import com.company.team.bussiness.lottery.facade.*;//領域防腐層
    代碼演示2 模塊的組織

      每個模塊的具體實現,我們將在下文中展開。

      領域對象

      前文提到,領域驅動要解決的一個重要的問題,就是解決對象的貧血問題。這里我們用之前定義的抽獎(DrawLottery)聚合根和獎池(AwardPool)值對象來具體說明。

      抽獎聚合根持有了抽獎活動的id和該活動下的所有可用獎池列表,它的一個最主要的領域功能就是根據一個抽獎發生場景(DrawLotteryContext),選擇出一個適配的獎池,即chooseAwardPool方法。

      chooseAwardPool的邏輯是這樣的:DrawLotteryContext會帶有用戶抽獎時的場景信息(抽獎得分或抽獎時所在的城市),DrawLottery會根據這個場景信息,匹配一個可以給用戶發獎的AwardPool。

    package com.company.team.bussiness.lottery.domain.aggregate;
    import ...;
    
    public class DrawLottery {
        private int lotteryId; //抽獎id
        private List<AwardPool> awardPools; //獎池列表
    
        //getter & setter
        public void setLotteryId(int lotteryId) {
            if(id<=0){
                throw new IllegalArgumentException("非法的抽獎id"); 
            }
            this.lotteryId = lotteryId;
        }
    
        //根據抽獎入參context選擇獎池
        public AwardPool chooseAwardPool(DrawLotteryContext context) {
            if(context.getMtCityInfo()!=null) {
                return chooseAwardPoolByCityInfo(awardPools, context.getMtCityInfo());
            } else {
                return chooseAwardPoolByScore(awardPools, context.getGameScore());
            }
        }
    
        //根據抽獎所在城市選擇獎池
        private AwardPool chooseAwardPoolByCityInfo(List<AwardPool> awardPools, MtCifyInfo cityInfo) {
            for(AwardPool awardPool: awardPools) {
                if(awardPool.matchedCity(cityInfo.getCityId())) {
                    return awardPool;
                }
            }
            return null;
        }
    
        //根據抽獎活動得分選擇獎池
        private AwardPool chooseAwardPoolByScore(List<AwardPool> awardPools, int gameScore) {...}
    }
    代碼演示3 DrawLottery

      在匹配到一個具體的獎池之后,需要確定最后給用戶的獎品是什么。這部分的領域功能在AwardPool內。

    package com.company.team.bussiness.lottery.domain.valobj;
    import ...;
    
    public class AwardPool {
        private String cityIds;//獎池支持的城市
        private String scores;//獎池支持的得分
        private int userGroupType;//獎池匹配的用戶類型
        private List<Awrad> awards;//獎池中包含的獎品
    
        //當前獎池是否與城市匹配
        public boolean matchedCity(int cityId) {...}
    
        //當前獎池是否與用戶得分匹配
        public boolean matchedScore(int score) {...}
    
        //根據概率選擇獎池
        public Award randomGetAward() {
            int sumOfProbablity = 0;
            for(Award award: awards) {
                sumOfProbability += award.getAwardProbablity();
            }
            int randomNumber = ThreadLocalRandom.current().nextInt(sumOfProbablity);
            range = 0;
            for(Award award: awards) {
                range += award.getProbablity();
                if(randomNumber<range) {
                    return award;
                }
            }
            return null;
        }
    }
    代碼演示4 AwardPool

      與以往的僅有getter、setter的業務對象不同,領域對象具有了行為,對象更加豐滿。同時,比起將這些邏輯寫在服務內(例如**Service),領域功能的內聚性更強,職責更加明確。

      資源庫

      領域對象需要資源存儲,存儲的手段可以是多樣化的,常見的無非是數據庫,分布式緩存,本地緩存等。資源庫(Repository)的作用,就是對領域的存儲和訪問進行統一管理的對象。在抽獎平臺中,我們是通過如下的方式組織資源庫的。

    //數據庫資源
    import com.company.team.bussiness.lottery.repo.dao.AwardPoolDao;//數據庫訪問對象-獎池
    import com.company.team.bussiness.lottery.repo.dao.AwardDao;//數據庫訪問對象-獎品
    import com.company.team.bussiness.lottery.repo.dao.po.AwardPO;//數據庫持久化對象-獎品
    import com.company.team.bussiness.lottery.repo.dao.po.AwardPoolPO;//數據庫持久化對象-獎池
    
    import com.company.team.bussiness.lottery.repo.cache.DrawLotteryCacheAccessObj;//分布式緩存訪問對象-抽獎緩存訪問
    import com.company.team.bussiness.lottery.repo.repository.DrawLotteryRepository;//資源庫訪問對象-抽獎資源庫
    代碼演示5 Repository組織結構

      資源庫對外的整體訪問由Repository提供,它聚合了各個資源庫的數據信息,同時也承擔了資源存儲的邏輯(例如緩存更新機制等)。

      在抽獎資源庫中,我們屏蔽了對底層獎池和獎品的直接訪問,而是僅對抽獎的聚合根進行資源管理。代碼示例中展示了抽獎資源獲取的方法(最常見的Cache Aside Pattern)。

      比起以往將資源管理放在服務中的做法,由資源庫對資源進行管理,職責更加明確,代碼的可讀性和可維護性也更強。

    package com.company.team.bussiness.lottery.repo;
    import ...;
    
    @Repository
    public class DrawLotteryRepository {
        @Autowired
        private AwardDao awardDao;
        @Autowired
        private AwardPoolDao awardPoolDao;
        @AutoWired
        private DrawLotteryCacheAccessObj drawLotteryCacheAccessObj;
    
        public DrawLottery getDrawLotteryById(int lotteryId) {
            DrawLottery drawLottery = drawLotteryCacheAccessObj.get(lotteryId);
            if(drawLottery!=null){
                return drawLottery;
            }
            drawLottery = getDrawLotteyFromDB(lotteryId);
            drawLotteryCacheAccessObj.add(lotteryId, drawLottery);
            return drawLottery;
        }
    
        private DrawLottery getDrawLotteryFromDB(int lotteryId) {...}
    }
    代碼演示6 DrawLotteryRepository

      防腐層

      亦稱適配層。在一個上下文中,有時需要對外部上下文進行訪問,通常會引入防腐層的概念來對外部上下文的訪問進行一次轉義。

      有以下幾種情況會考慮引入防腐層:

    • 需要將外部上下文中的模型翻譯成本上下文理解的模型。
    • 不同上下文之間的團隊協作關系,如果是供奉者關系,建議引入防腐層,避免外部上下文變化對本上下文的侵蝕。
    • 該訪問本上下文使用廣泛,為了避免改動影響范圍過大。

      如果內部多個上下文對外部上下文需要訪問,那么可以考慮將其放到通用上下文中。

      在抽獎平臺中,我們定義了用戶城市信息防腐層(UserCityInfoFacade),用于外部的用戶城市信息上下文(微服務架構下表現為用戶城市信息服務)。

      以用戶信息防腐層舉例,它以抽獎請求參數(LotteryContext)為入參,以城市信息(MtCityInfo)為輸出。

    package com.company.team.bussiness.lottery.facade;
    import ...;
    
    @Component
    public class UserCityInfoFacade {
        @Autowired
        private LbsService lbsService;//外部用戶城市信息RPC服務
    
        public MtCityInfo getMtCityInfo(LotteryContext context) {
            LbsReq lbsReq = new LbsReq();
            lbsReq.setLat(context.getLat());
            lbsReq.setLng(context.getLng());
            LbsResponse resp = lbsService.getLbsCityInfo(lbsReq);
            return buildMtCifyInfo(resp);
        }
    
        private MtCityInfo buildMtCityInfo(LbsResponse resp) {...}
    }
    代碼演示7 UserCityInfoFacade

      領域服務

      上文中,我們將領域行為封裝到領域對象中,將資源管理行為封裝到資源庫中,將外部上下文的交互行為封裝到防腐層中。此時,我們再回過頭來看領域服務時,能夠發現領域服務本身所承載的職責也就更加清晰了,即就是通過串聯領域對象、資源庫和防腐層等一系列領域內的對象的行為,對其他上下文提供交互的接口。

      我們以抽獎服務為例(issueLottery),可以看到在省略了一些防御性邏輯(異常處理,空值判斷等)后,領域服務的邏輯已經足夠清晰明了。

    package com.company.team.bussiness.lottery.service.impl
    import ...;
    
    @Service
    public class LotteryServiceImpl implements LotteryService {
        @Autowired
        private DrawLotteryRepository drawLotteryRepo;
        @Autowired
        private UserCityInfoFacade UserCityInfoFacade;
        @Autowired
        private AwardSendService awardSendService;
        @Autowired
        private AwardCounterFacade awardCounterFacade;
    
        @Override
        public IssueResponse issueLottery(LotteryContext lotteryContext) {
            DrawLottery drawLottery = drawLotteryRepo.getDrawLotteryById(lotteryContext.getLotteryId());//獲取抽獎配置聚合根
            awardCounterFacade.incrTryCount(lotteryContext);//增加抽獎計數信息
            AwardPool awardPool = lotteryConfig.chooseAwardPool(bulidDrawLotteryContext(drawLottery, lotteryContext));//選中獎池
            Award award = awardPool.randomChooseAward();//選中獎品
            return buildIssueResponse(awardSendService.sendAward(award, lotteryContext));//發出獎品實體
        }
    
        private IssueResponse buildIssueResponse(AwardSendResponse awardSendResponse) {...}
    }
    代碼演示8 LotteryService

      數據流轉

      在抽獎平臺的實踐中,我們的數據流轉如上圖所示。

      首先領域的開放服務通過信息傳輸對象(DTO)來完成與外界的數據交互;在領域內部,我們通過領域對象(DO)作為領域內部的數據和行為載體;在資源庫內部,我們沿襲了原有的數據庫持久化對象(PO)進行數據庫資源的交互。同時,DTO與DO的轉換發生在領域服務內,DO與PO的轉換發生在資源庫內。

      與以往的業務服務相比,當前的編碼規范可能多造成了一次數據轉換,但每種數據對象職責明確,數據流轉更加清晰。

      上下文集成

      通常集成上下文的手段有多種,常見的手段包括開放領域服務接口、開放HTTP服務以及消息發布-訂閱機制。

      在抽獎系統中,我們使用的是開放服務接口進行交互的。最明顯的體現是計數上下文,它作為一個通用上下文,對抽獎、風控、活動準入等上下文都提供了訪問接口。

      同時,如果在一個上下文對另一個上下文進行集成時,若需要一定的隔離和適配,可以引入防腐層的概念。這一部分的示例可以參考前文的防腐層代碼示例。

      分離領域

      接下來講解在實施領域模型的過程中,如何應用到系統架構中。

      我們采用的微服務架構風格,與Vernon在《實現領域驅動設計》并不太一致,更具體差異可閱讀他的書體會。

      如果我們維護一個從前到后的應用系統:

      下圖中領域服務是使用微服務技術剝離開來,獨立部署,對外暴露的只能是服務接口,領域對外暴露的業務邏輯只能依托于領域服務。而在Vernon著作中,并未假定微服務架構風格,因此領域層暴露的除了領域服務外,還有聚合、實體和值對象等。此時的應用服務層是比較簡單的,獲取來自接口層的請求參數,調度多個領域服務以實現界面層功能。

      隨著業務發展,業務系統快速膨脹,我們的系統屬于核心時:

      應用服務雖然沒有領域邏輯,但涉及到了對多個領域服務的編排。當業務規模龐大到一定程度,編排本身就富含了業務邏輯(除此之外,應用服務在穩定性、性能上所做的措施也希望統一起來,而非散落各處),那么此時應用服務對于外部來說是一個領域服務,整體看起來則是一個獨立的限界上下文。

      此時應用服務對內還屬于應用服務,對外已是領域服務的概念,需要將其暴露為微服務。

      注:具體的架構實踐可按照團隊和業務的實際情況來,此處僅為作者自身的業務實踐。除分層架構外,如CQRS架構也是不錯的選擇

      以下是一個示例。我們定義了抽獎、活動準入、風險控制等多個領域服務。在本系統中,我們需要集成多個領域服務,為客戶端提供一套功能完備的抽獎應用服務。這個應用服務的組織如下:

    package ...;
    
    import ...;
    
    @Service
    public class LotteryApplicationService {
        @Autowired
        private LotteryRiskService riskService;
        @Autowired
        private LotteryConditionService conditionService;
        @Autowired
        private LotteryService lotteryService;
    
        //用戶參與抽獎活動
        public Response<PrizeInfo, ErrorData> participateLottery(LotteryContext lotteryContext) {
            //校驗用戶登錄信息
            validateLoginInfo(lotteryContext);
            //校驗風控 
            RiskAccessToken riskToken = riskService.accquire(buildRiskReq(lotteryContext));
            ...
            //活動準入檢查
            LotteryConditionResult conditionResult = conditionService.checkLotteryCondition(otteryContext.getLotteryId(),lotteryContext.getUserId());
            ...
            //抽獎并返回結果
            IssueResponse issueResponse = lotteryService.issurLottery(lotteryContext);
            if(issueResponse!=null && issueResponse.getCode()==IssueResponse.OK) {
                return buildSuccessResponse(issueResponse.getPrizeInfo());
            } else {   
                return buildErrorResponse(ResponseCode.ISSUE_LOTTERY_FAIL, ResponseMsg.ISSUE_LOTTERY_FAIL)
            }
        }
    
        private void validateLoginInfo(LotteryContext lotteryContext){...}
        private Response<PrizeInfo, ErrorData> buildErrorResponse (int code, String msg){...}
        private Response<PrizeInfo, ErrorData> buildSuccessResponse (PrizeInfo prizeInfo){...}
    }
    代碼演示9 LotteryApplicationService

      結語

      在本文中,我們采用了分治的思想,從抽象到具體闡述了DDD在互聯網真實業務系統中的實踐。通過領域驅動設計這個強大的武器,我們將系統解構的更加合理。

      但值得注意的是,如果你面臨的系統很簡單或者做一些SmartUI之類,那么你不一定需要DDD。盡管本文對貧血模型、演進式設計提出了些許看法,但它們在特定范圍和具體場景下會更高效。讀者需要針對自己的實際情況,做一定取舍,適合自己的才是最好的。

      本篇通過DDD來講述軟件設計的術與器,本質是為了高內聚低耦合,緊靠本質,按自己的理解和團隊情況來實踐DDD即可。

      另外,關于DDD在迭代過程中模型腐化的相關問題,本文中沒有提及,將在后續的文章中論述,敬請期待。

      鑒于作者經驗有限,我們對領域驅動的理解難免會有不足之處,歡迎大家共同探討,共同提高。

      參考書籍

    Eric Evans 《領域驅動設計》趙俐 盛海艷 劉霞等譯. 人民郵電出版社,2016.
    Vaughn Vernon《實現領域驅動設計》滕云譯. 電子工業出版社,2014.

    33
    0
    標簽:DDD 架構設計

    軟件設計熱門文章

      軟件設計最新文章

        最新新聞

          熱門新聞

            黄色网_免费在线黄色电影_黄色成人快播电影_伦理电影_黄色片