第一單元
領(lǐng)域建模的方法 1、領(lǐng)域建模與設(shè)計的關(guān)系
優(yōu)秀的軟件系統(tǒng)與好的軟件設(shè)計息息相關(guān),但最關(guān)鍵的還是在于對需求的理解。如果不能正確的理解軟件需求,那么再好的設(shè)計也不能設(shè)計出好的軟件。正確的做事情固然重要,更重要的是要做正確的事。然而,需求到設(shè)計存在巨大的鴻溝,因為需求是站在業(yè)務(wù)角度來考慮,而設(shè)計往往會站在實現(xiàn)角度。領(lǐng)域建模就是為這二者搭建一個溝通與轉(zhuǎn)換的橋梁。
2、統(tǒng)一語言(Ubiquitous Language)
為了更好的理解需求,我們需要與領(lǐng)域?qū)<乙黄鹗崂砟繕?biāo)領(lǐng)域的統(tǒng)一語言,從而就領(lǐng)域術(shù)語達成一致,并有利于領(lǐng)域建模。
第二單元
領(lǐng)域驅(qū)動設(shè)計的戰(zhàn)略設(shè)計
1、限界上下文(Bounded Context)
若要進行領(lǐng)域建模,并將業(yè)務(wù)需求逐步演化為架構(gòu)設(shè)計,則需要引入DDD(領(lǐng)域驅(qū)動設(shè)計)的戰(zhàn)略設(shè)計作為指導(dǎo)。場景圖與限界上下文可以很好地結(jié)合,幫助架構(gòu)師很好地識別各個子領(lǐng)域的概念邊界與設(shè)計邊界。如此則可以運用“分而治之”的思想識別出整個系統(tǒng)的業(yè)務(wù)邏輯邊界與物理邊界。
2、場景驅(qū)動
場景驅(qū)動設(shè)計的核心在于識別場景,它需要設(shè)計者結(jié)合具體的業(yè)務(wù)場景,分析業(yè)務(wù)流程,以此驅(qū)動出用例;再以用例驅(qū)動對業(yè)務(wù)邏輯的建模。場景驅(qū)動設(shè)計的核心模型為6W模型,即Who,Why,When,What,Where與hoW。它將對應(yīng)職責(zé)模型的業(yè)務(wù)價值、業(yè)務(wù)功能與業(yè)務(wù)實現(xiàn),并從角色的角度思考對象之間的協(xié)作以及設(shè)計邊界。
3、用例方法 (Use Case)
通過利用傳統(tǒng)的用例方法來幫助我們驅(qū)動出領(lǐng)域的限界上下文。
可視化演練:識別電子商務(wù)系統(tǒng)的限界上下文
4、上下文映射圖 (Context Map)
本部分內(nèi)容會講解限界上下文之間主要存在的組織模式與集成模式,這其中包括防腐層,開放服務(wù)調(diào)用等。利用上下文映射圖,有助于識別上下文之間的關(guān)系,思考處于上下文內(nèi)領(lǐng)域模型之間的通信方式,從而幫助架構(gòu)師驅(qū)動出最終的應(yīng)用邏輯架構(gòu)。
可視化演練:電子商務(wù)系統(tǒng)的應(yīng)用邏輯架構(gòu)
第三單元
領(lǐng)域驅(qū)動設(shè)計的架構(gòu)設(shè)計 1、分層架構(gòu) (Layered Architecture)
分層架構(gòu)模式是應(yīng)用最為廣泛的架構(gòu)模式,它根據(jù)關(guān)注點分離的架構(gòu)原則,針對表現(xiàn)層、領(lǐng)域?qū)雍突A(chǔ)設(shè)施層進行層次分離。本次培訓(xùn)將以全新視角審視分層架構(gòu),針對大型軟件系統(tǒng)分析該如何進行分層架構(gòu)設(shè)計。
案例分析:網(wǎng)上銀行的分層架構(gòu),根據(jù)最基本的業(yè)務(wù)流程對系統(tǒng)進行關(guān)注點分離,繪制系統(tǒng)的分層架構(gòu),并通過時序圖展現(xiàn)各層之間的協(xié)作。
2、六邊形架構(gòu) (Hexagonal Architecture)
雖然分層架構(gòu)仍然是運用最為廣泛的架構(gòu)模式,同時更是諸多架構(gòu)模式的基礎(chǔ),但它已不足以描述越來越復(fù)雜的分布式系統(tǒng)架構(gòu)。由Cockburn提出的六邊形架構(gòu)(Hexagonal Architecture)是一種具有對稱性特征的架構(gòu)風(fēng)格。在這種架構(gòu)中,不同的客戶通過“平等”的方式與系統(tǒng)交互。該架構(gòu)中存在兩個區(qū)域,分別是“外部區(qū)域”和“內(nèi)部區(qū)域”。這種界定了明確內(nèi)外邊界的架構(gòu)風(fēng)格,更有利于架構(gòu)師實現(xiàn)關(guān)注點分離,并將關(guān)注重心放在適配器與通信端口上。
演練:六邊形架構(gòu)的通信邊界
案例:大型金融系統(tǒng)的客戶管理
3、CQRS
CQRS風(fēng)格,即命令查詢職責(zé)分離(Command Query Responsibility Segregation),它結(jié)合了消息處理、事件處理的架構(gòu)風(fēng)格,是對多種設(shè)計模式的綜合運用,適用于處理讀寫比例高,需要支持可伸縮性的大型系統(tǒng)。
案例:AxonFramework對CQRS的支持
4、事件驅(qū)動架構(gòu) (Event-Driven Architecture)
事件驅(qū)動架構(gòu)(Event-Driven Architecture,EDA)是一種用于處理事件生成、發(fā)現(xiàn)和處理等任務(wù)的軟件架構(gòu)。事件往往對應(yīng)于軟件系統(tǒng)的狀態(tài)機,狀態(tài)的遷移就是用事件來觸發(fā)的。因而,事件能夠很好地體現(xiàn)這樣的業(yè)務(wù)模型。同時,基于事件的軟件架構(gòu)可以幫助我們更好地建立松散耦合的模塊化架構(gòu)。
第四單元
領(lǐng)域驅(qū)動設(shè)計的戰(zhàn)術(shù)設(shè)計 1、領(lǐng)域模型
通過限界上下文,可以幫助我們分析系統(tǒng)的領(lǐng)域模型,包括系統(tǒng)的核心領(lǐng)域與子領(lǐng)域。確定系統(tǒng)的核心領(lǐng)域與子領(lǐng)域可以幫助架構(gòu)師合理分配資源(包括時間資源與人力資源)。而對子領(lǐng)域的進一步識別,可以幫助架構(gòu)師更好地識別可重用資源,包括可重用的功能模塊,確定技術(shù)棧,決定構(gòu)建還是購買的架構(gòu)戰(zhàn)略。
3、四色建模法
首先以滿足管理和運營的需要為前提,尋找需要追溯的事件。根據(jù)這些需要追溯,尋找足跡以及相應(yīng)的時標(biāo)性對象。尋找時標(biāo)對象周圍的人/事/物。從中抽象角色,把一些信息用描述對象補足。
案例分析:配送管理系統(tǒng)的四色建模
2、實體(Entity)與值對象(Value Object)
這兩個概念都是領(lǐng)域?qū)ο蟮捏w現(xiàn),二者的主要區(qū)別在于對“標(biāo)識”的運用。本部分的內(nèi)容深入展開對實體標(biāo)識的討論,揭示實體的本質(zhì)特征,挖掘?qū)嶓w的關(guān)鍵行為。通過識別角色與職責(zé)對實現(xiàn)進行分析。
本部分內(nèi)容還將通過深入講解值對象的特征幫助我們分辨值對象與實體,使得我們可以在領(lǐng)域驅(qū)動設(shè)計中有效地運用實體與值對象。本部分內(nèi)容還包括持久化值對象,以及領(lǐng)域驅(qū)動設(shè)計與ORM之間的關(guān)系。
3、領(lǐng)域服務(wù) (Domain Service)
通過講解什么是領(lǐng)域服務(wù),什么不是領(lǐng)域服務(wù)理清領(lǐng)域服務(wù)的概念,并講解如何建模領(lǐng)域服務(wù)。討論領(lǐng)域服務(wù)和面向接口設(shè)計思想。
4、領(lǐng)域事件 (Domain Event)
事件驅(qū)動架構(gòu)的主要對象即為領(lǐng)域事件,我們要分清在何時以及為什么要使用領(lǐng)域事件,并對領(lǐng)域事件進行建模。通過講解發(fā)布者-訂閱者模式講解如何在領(lǐng)域模型和限界上下文中發(fā)布領(lǐng)域事件。同時,針對事件進行存儲的Event Source也與CQRS架構(gòu)風(fēng)格直接相關(guān)。
演練:尋找領(lǐng)域事件
5、聚合 (Aggregation)
聚合是領(lǐng)域驅(qū)動設(shè)計最為重要的領(lǐng)域概念。本部分內(nèi)容將深入探討聚合的設(shè)計原則,并辨別在聚合設(shè)計中可能出現(xiàn)的壞味道,并提出針對性的解決方案。這些原則和方案包括:在一致性邊界之內(nèi)建模真正的不變量,設(shè)計小的聚合,通過唯一標(biāo)識引用其他聚合,在邊界外滿足最終一致性。
6、工廠(Factory)和資源庫(Repository)
工廠和資源庫都是管理領(lǐng)域?qū)ο螅▽嶓w、值對象和服務(wù))生命周期的對象。工廠主要針對內(nèi)存中對象從無到有的創(chuàng)建過程,與設(shè)計模式的工廠模式基本相似。
資源庫則分為面向集合的資源庫與面向持久化的資源庫。本部分內(nèi)容將重點講解與資源庫直接相關(guān)的技術(shù)細節(jié),包括如何選擇資源庫的方式,如何針對聚合持久化資源庫,如何管理事務(wù),以及分辨資源庫與數(shù)據(jù)訪問對象(DAO)之間的異同。
7、應(yīng)用層(Application Layer)設(shè)計
作為為UI提供的應(yīng)用服務(wù),其目的在于管理和協(xié)調(diào)領(lǐng)域?qū)ο螅轭I(lǐng)域?qū)ο筇峁M切關(guān)注點的內(nèi)容。好的應(yīng)用服務(wù)設(shè)計不應(yīng)該承擔(dān)任何與領(lǐng)域邏輯有關(guān)的職責(zé)。應(yīng)用層是架構(gòu)層面的外觀與適配器模式的體現(xiàn)。它可以提高軟件系統(tǒng)架構(gòu)的可用性與簡單性,也能夠更好地與面向服務(wù)架構(gòu)或RESTful架構(gòu)風(fēng)格結(jié)合。
第五單元
DCI
Transaction Script與Domain Model之爭
貧血模型與充血模型之爭
Service廢存的爭論
2、DCI(Data Context Interation)
DCI是領(lǐng)域驅(qū)動設(shè)計的一個分支,更加關(guān)注系統(tǒng)的行為,從而提高代碼的可讀性。該范式將Data Model(data)從Use Cases(context)以及對象扮演的Role(Interaction)中分離出來。 |