領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)與系統(tǒng)重構(gòu)以及API設(shè)計(jì)_第1頁
領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)與系統(tǒng)重構(gòu)以及API設(shè)計(jì)_第2頁
領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)與系統(tǒng)重構(gòu)以及API設(shè)計(jì)_第3頁
領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)與系統(tǒng)重構(gòu)以及API設(shè)計(jì)_第4頁
領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)與系統(tǒng)重構(gòu)以及API設(shè)計(jì)_第5頁
已閱讀5頁,還剩1頁未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

1、領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)與系統(tǒng)重構(gòu)以及API設(shè)計(jì)1 培訓(xùn)目標(biāo)需求分析人員和領(lǐng)域?qū)<覠o法與團(tuán)隊(duì)的設(shè)計(jì)人員和開發(fā)人員進(jìn)行有效溝通。需求分析人員不了解軟件設(shè)計(jì),軟件設(shè)計(jì)人員常常會(huì)曲解需求內(nèi)容,這是軟件開發(fā)中容易出現(xiàn)的第一病癥。它帶來的后果是設(shè)計(jì)頻繁變更,設(shè)計(jì)的軟件不滿足客戶需求。需求分析雖然明白無誤,設(shè)計(jì)人員卻無法準(zhǔn)確地抽象領(lǐng)域模型,從而不能開展有效的軟件設(shè)計(jì),這是軟件開發(fā)中容易出現(xiàn)的第二病癥。它帶來的后果是設(shè)計(jì)質(zhì)量糟糕,開發(fā)的代碼不具有良好的可讀性,增加了軟件的開發(fā)與維護(hù)成本。系統(tǒng)的業(yè)務(wù)需求復(fù)雜多變,設(shè)計(jì)人員卻總是喜歡從實(shí)現(xiàn)角度以及數(shù)據(jù)庫層面思考業(yè)務(wù)問題,這是軟件開發(fā)中容易出現(xiàn)的第三病癥。它會(huì)導(dǎo)致開發(fā)的系統(tǒng)過

2、于復(fù)雜,且可擴(kuò)展性差,無法有效應(yīng)對(duì)需求發(fā)生的變化。無論設(shè)計(jì)多么合理,面對(duì)需求變化時(shí),我們都需要對(duì)現(xiàn)有設(shè)計(jì)進(jìn)行改進(jìn)。領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)可以在一定程度上保證設(shè)計(jì)的質(zhì)量,而重構(gòu)則可以保證在付出較小成本的前提下調(diào)整與改善設(shè)計(jì),從而更好地滿足需求變化。本次培訓(xùn)的內(nèi)容領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)與系統(tǒng)重構(gòu)正好是解決這三種常見病癥的最佳藥方。2 培訓(xùn)計(jì)劃時(shí)間課題內(nèi)容第一天(上午)第一單元領(lǐng)域建模的方法1、領(lǐng)域建模與設(shè)計(jì)的關(guān)系優(yōu)秀的軟件系統(tǒng)與好的軟件設(shè)計(jì)息息相關(guān),但最關(guān)鍵的還是在于對(duì)需求的理解。如果不能正確的理解軟件需求,那么再好的設(shè)計(jì)也不能設(shè)計(jì)出好的軟件。正確的做事情固然重要,更重要的是要做正確的事。然而,需求到設(shè)計(jì)存在巨大的鴻

3、溝,因?yàn)樾枨笫钦驹跇I(yè)務(wù)角度來考慮,而設(shè)計(jì)往往會(huì)站在實(shí)現(xiàn)角度。領(lǐng)域建模就是為這二者搭建一個(gè)溝通與轉(zhuǎn)換的橋梁。2、統(tǒng)一語言(Ubiquitous Language)為了更好的理解需求,我們需要與領(lǐng)域?qū)<乙黄鹗崂砟繕?biāo)領(lǐng)域的統(tǒng)一語言,從而就領(lǐng)域術(shù)語達(dá)成一致,并有利于領(lǐng)域建模。第二單元領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的戰(zhàn)略設(shè)計(jì)1、限界上下文(Bounded Context)若要進(jìn)行領(lǐng)域建模,并將業(yè)務(wù)需求逐步演化為架構(gòu)設(shè)計(jì),則需要引入DDD(領(lǐng)域驅(qū)動(dòng)設(shè)計(jì))的戰(zhàn)略設(shè)計(jì)作為指導(dǎo)。場(chǎng)景圖與限界上下文可以很好地結(jié)合,幫助架構(gòu)師很好地識(shí)別各個(gè)子領(lǐng)域的概念邊界與設(shè)計(jì)邊界。如此則可以運(yùn)用“分而治之”的思想識(shí)別出整個(gè)系統(tǒng)的業(yè)務(wù)邏輯邊界與物理

4、邊界。2、用例方法 (Use Case)通過利用傳統(tǒng)的用例方法來幫助我們驅(qū)動(dòng)出領(lǐng)域的限界上下文??梢暬菥殻鹤R(shí)別電子商務(wù)系統(tǒng)的限界上下文3、上下文映射圖 (Context Map)本部分內(nèi)容會(huì)講解限界上下文之間主要存在的組織模式與集成模式,這其中包括防腐層,開放服務(wù)調(diào)用等。利用上下文映射圖,有助于識(shí)別上下文之間的關(guān)系,思考處于上下文內(nèi)領(lǐng)域模型之間的通信方式,從而幫助架構(gòu)師驅(qū)動(dòng)出最終的應(yīng)用邏輯架構(gòu)??梢暬菥殻弘娮由虅?wù)系統(tǒng)的應(yīng)用邏輯架構(gòu)第一天(下午)第三單元領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的架構(gòu)設(shè)計(jì)1、分層架構(gòu) (Layered Architecture)分層架構(gòu)模式是應(yīng)用最為廣泛的架構(gòu)模式,它根據(jù)關(guān)注點(diǎn)分離的架構(gòu)

5、原則,針對(duì)表現(xiàn)層、領(lǐng)域?qū)雍突A(chǔ)設(shè)施層進(jìn)行層次分離。本次培訓(xùn)將以全新視角審視分層架構(gòu),針對(duì)大型軟件系統(tǒng)分析該如何進(jìn)行分層架構(gòu)設(shè)計(jì)。案例分析:網(wǎng)上銀行的分層架構(gòu),根據(jù)最基本的業(yè)務(wù)流程對(duì)系統(tǒng)進(jìn)行關(guān)注點(diǎn)分離,繪制系統(tǒng)的分層架構(gòu),并通過時(shí)序圖展現(xiàn)各層之間的協(xié)作。2、六邊形架構(gòu) (Hexagonal Architecture)雖然分層架構(gòu)仍然是運(yùn)用最為廣泛的架構(gòu)模式,同時(shí)更是諸多架構(gòu)模式的基礎(chǔ),但它已不足以描述越來越復(fù)雜的分布式系統(tǒng)架構(gòu)。由Cockburn提出的六邊形架構(gòu)(Hexagonal Architecture)是一種具有對(duì)稱性特征的架構(gòu)風(fēng)格。在這種架構(gòu)中,不同的客戶通過“平等”的方式與系統(tǒng)交互。該

6、架構(gòu)中存在兩個(gè)區(qū)域,分別是“外部區(qū)域”和“內(nèi)部區(qū)域”。這種界定了明確內(nèi)外邊界的架構(gòu)風(fēng)格,更有利于架構(gòu)師實(shí)現(xiàn)關(guān)注點(diǎn)分離,并將關(guān)注重心放在適配器與通信端口上。演練:六邊形架構(gòu)的通信邊界案例:大型金融系統(tǒng)的客戶管理第二天(上午)第四單元領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的戰(zhàn)術(shù)設(shè)計(jì)1、領(lǐng)域模型通過限界上下文,可以幫助我們分析系統(tǒng)的領(lǐng)域模型,包括系統(tǒng)的核心領(lǐng)域與子領(lǐng)域。確定系統(tǒng)的核心領(lǐng)域與子領(lǐng)域可以幫助架構(gòu)師合理分配資源(包括時(shí)間資源與人力資源)。而對(duì)子領(lǐng)域的進(jìn)一步識(shí)別,可以幫助架構(gòu)師更好地識(shí)別可重用資源,包括可重用的功能模塊,確定技術(shù)棧,決定構(gòu)建還是購買的架構(gòu)戰(zhàn)略。3、四色建模法首先以滿足管理和運(yùn)營(yíng)的需要為前提,尋找需要追

7、溯的事件。根據(jù)這些需要追溯,尋找足跡以及相應(yīng)的時(shí)標(biāo)性對(duì)象。尋找時(shí)標(biāo)對(duì)象周圍的人事物。從中抽象角色,把一些信息用描述對(duì)象補(bǔ)足。案例分析:配送管理系統(tǒng)的四色建模2、實(shí)體(Entity)與值對(duì)象(Value Object)這兩個(gè)概念都是領(lǐng)域?qū)ο蟮捏w現(xiàn),二者的主要區(qū)別在于對(duì)“標(biāo)識(shí)”的運(yùn)用。本部分的內(nèi)容深入展開對(duì)實(shí)體標(biāo)識(shí)的討論,揭示實(shí)體的本質(zhì)特征,挖掘?qū)嶓w的關(guān)鍵行為。通過識(shí)別角色與職責(zé)對(duì)實(shí)現(xiàn)進(jìn)行分析。本部分內(nèi)容還將通過深入講解值對(duì)象的特征幫助我們分辨值對(duì)象與實(shí)體,使得我們可以在領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)中有效地運(yùn)用實(shí)體與值對(duì)象。本部分內(nèi)容還包括持久化值對(duì)象,以及領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)與ORM之間的關(guān)系。3、領(lǐng)域服務(wù) (Doma

8、in Service)通過講解什么是領(lǐng)域服務(wù),什么不是領(lǐng)域服務(wù)理清領(lǐng)域服務(wù)的概念,并講解如何建模領(lǐng)域服務(wù)。討論領(lǐng)域服務(wù)和面向接口設(shè)計(jì)思想。 4、聚合 (Aggregation)聚合是領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)最為重要的領(lǐng)域概念。本部分內(nèi)容將深入探討聚合的設(shè)計(jì)原則,并辨別在聚合設(shè)計(jì)中可能出現(xiàn)的壞味道,并提出針對(duì)性的解決方案。這些原則和方案包括:在一致性邊界之內(nèi)建模真正的不變量,設(shè)計(jì)小的聚合,通過唯一標(biāo)識(shí)引用其他聚合,在邊界外滿足最終一致性。5、工廠(Factory)和資源庫(Repository)工廠和資源庫都是管理領(lǐng)域?qū)ο螅▽?shí)體、值對(duì)象和服務(wù))生命周期的對(duì)象。工廠主要針對(duì)內(nèi)存中對(duì)象從無到有的創(chuàng)建過程,與設(shè)計(jì)

9、模式的工廠模式基本相似。資源庫則分為面向集合的資源庫與面向持久化的資源庫。本部分內(nèi)容將重點(diǎn)講解與資源庫直接相關(guān)的技術(shù)細(xì)節(jié),包括如何選擇資源庫的方式,如何針對(duì)聚合持久化資源庫,如何管理事務(wù),以及分辨資源庫與數(shù)據(jù)訪問對(duì)象(DAO)之間的異同。7、應(yīng)用層(Application Layer)設(shè)計(jì)作為為UI提供的應(yīng)用服務(wù),其目的在于管理和協(xié)調(diào)領(lǐng)域?qū)ο?,并為領(lǐng)域?qū)ο筇峁M切關(guān)注點(diǎn)的內(nèi)容。好的應(yīng)用服務(wù)設(shè)計(jì)不應(yīng)該承擔(dān)任何與領(lǐng)域邏輯有關(guān)的職責(zé)。應(yīng)用層是架構(gòu)層面的外觀與適配器模式的體現(xiàn)。它可以提高軟件系統(tǒng)架構(gòu)的可用性與簡(jiǎn)單性,也能夠更好地與面向服務(wù)架構(gòu)或RESTful架構(gòu)風(fēng)格結(jié)合。第二天(下午)第五單元系統(tǒng)重構(gòu)

10、1、軟件業(yè)者的反思: 軟件腐爛隱匿的腐爛:軟件逐漸不再(仍)被使用隨著剩余的應(yīng)用程序的改變變得不能用。它已經(jīng)被觀察到不再被使用的軟件有可能一年的半衰期;活動(dòng)的腐爛:軟件隨著不斷地被修改趨向于失去它的完整性。2、破窗效應(yīng)與技術(shù)債務(wù)技術(shù)債務(wù)是不可避免的,然而對(duì)技術(shù)債務(wù)視而不見,則可以導(dǎo)致破窗效應(yīng)。3、重構(gòu)· 何時(shí)重構(gòu)· 重構(gòu)的誤區(qū)· 重構(gòu)是持續(xù)進(jìn)行的,不要先編寫爛代碼,再抽出重構(gòu)· 如何發(fā)現(xiàn)哪些地方需要重構(gòu)· 如何保證重構(gòu)的正確· 如何測(cè)試重構(gòu)4、重構(gòu)技術(shù)難題· 如何發(fā)現(xiàn)重構(gòu)點(diǎn)· 知道重構(gòu)的目標(biāo)(結(jié)果)· 如

11、何去重構(gòu)重構(gòu)實(shí)踐· 如何保證重構(gòu)的正確性-單元測(cè)試第三天第六單元優(yōu)良API設(shè)計(jì)1、優(yōu)良API的特征API的設(shè)計(jì)與普通接口的設(shè)計(jì)有相似之處,需要遵循相同的設(shè)計(jì)原則,但要求會(huì)更嚴(yán)格。因此,優(yōu)良的API設(shè)計(jì)需要充分考慮API的可讀性、可擴(kuò)展性與可維護(hù)性以及可測(cè)試性。 2、API的演化與版本兼容性產(chǎn)品設(shè)計(jì)不可能一蹴而就,需要不停迭代和變化,從而產(chǎn)生版本變遷,API也將隨之演化。設(shè)計(jì)時(shí),需要考慮API的向后兼容,包括源代碼兼容、二進(jìn)制兼容與功能兼容。3、API設(shè)計(jì)的層次與粒度API設(shè)計(jì)與架構(gòu)直接相關(guān),需要考慮系統(tǒng)各模塊之間的松散耦合,以及模塊之間的通信方式。這些設(shè)計(jì)要素會(huì)直接決定API所處的層次以及設(shè)計(jì)粒度。4、REST風(fēng)格的API領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)中的開放主機(jī)服務(wù)(OHS)多數(shù)是以REST方式暴露出來的服務(wù)。在軟件領(lǐng)域中,服務(wù)成為越來越重要的重用單位,因而如何設(shè)計(jì)REST風(fēng)格

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

評(píng)論

0/150

提交評(píng)論