課程簡介
1、全真案例，借助案例與設(shè)計模式知識的原理，借助最佳實踐，幫助您提高設(shè)計能力，從而提高開發(fā)效率和設(shè)計質(zhì)量
2、以新視角，揭示模式的本質(zhì)、思想方法，剖析出模式之“道”，跳出“為模式而模式”的“陷阱”
3、提升設(shè)計能力，使開發(fā)人員由“編程小工”到設(shè)計專家
4、提出場景驅(qū)動設(shè)計，利用領(lǐng)域建模、職責(zé)驅(qū)動、擴展式設(shè)計以及重構(gòu)，提高軟件設(shè)計質(zhì)量，實現(xiàn)卓越軟件設(shè)計
5、關(guān)注業(yè)界內(nèi)設(shè)計模式，以實戰(zhàn)訓(xùn)練驅(qū)動對面向?qū)ο笤O(shè)計的理解與運用
目標(biāo)收益
1、員工無法接手遺留系統(tǒng)，原因是代碼雜亂，可讀性差
2、團隊成員沒有設(shè)計模式知識與經(jīng)驗，無法實施敏捷開發(fā)
3、系統(tǒng)難以重構(gòu)，不利于產(chǎn)品的重用與二次開發(fā)
4、開發(fā)效率得不到保障，因為詳細設(shè)計人員不能理解架構(gòu)文檔與詳細設(shè)計方案
5、設(shè)計方案難于應(yīng)對需求變更
6、設(shè)計的系統(tǒng)架構(gòu)缺乏可擴展性、可維護性和可測試性，不能合理地重用
7、架構(gòu)、設(shè)計、開發(fā)三個環(huán)節(jié)中各個角色不能理解設(shè)計意圖，很難溝通
培訓(xùn)對象
IT人員
課程大綱
|
第一單元： 面向?qū)ο笤O(shè)計： 角色、職責(zé)與協(xié)作 職責(zé)驅(qū)動設(shè)計 |
面向?qū)ο笤O(shè)計的核心驅(qū)動力是對象的職責(zé)，合理的職責(zé)分配是卓越軟件設(shè)計的前提。只有合理地分辨對象的職責(zé)，才能夠定義良好的對象，并實現(xiàn)符合系統(tǒng)一致性的對象協(xié)作關(guān)系。 1、職責(zé)的層次 通過職責(zé)層次模型對需求進行分析，識別出業(yè)務(wù)價值、業(yè)務(wù)功能與業(yè)務(wù)實現(xiàn)。職責(zé)層次的分解可以有效地幫助設(shè)計者辨別職責(zé)。 （1）職責(zé)層次的識別 （2）職責(zé)層次與軟件架構(gòu)層次之間的關(guān)系 （3）職責(zé)與概念、規(guī)約與實現(xiàn) （4）案例分析：分析郵件服務(wù)器代碼暴露的問題，在可重用性、代碼可維護性、可擴展性等諸多方面著手，剖析代碼壞味道。通過分辨職責(zé)層次，來改善設(shè)計。并提出需求變更，從而引入對Observer模式、Strategy模式、Simple Factory模式、Mediator模式與Chain Of Responsibility模式的對比與分析； （5）實戰(zhàn)演練：設(shè)計一個作業(yè)調(diào)度框架，它能夠根據(jù)指定的時間觸發(fā)作業(yè)，執(zhí)行自定義任務(wù)。 2、職責(zé)的分類 職責(zé)并不等于功能，也不等同于行為或方法。分析職責(zé)，應(yīng)從對象的認知與行為入手。 3、對象的角色 角色、職責(zé)與協(xié)作是三位一體的關(guān)系，角色是發(fā)起職責(zé)的對象，職責(zé)則應(yīng)該是對象之間的協(xié)作。不同角色的對象，履行的職責(zé)是不同的。 （1）信息持有者：信息的格式；是否需要持久化；信息源的改變，是否需要更新；處理信息的方式； （2）構(gòu)造者：構(gòu)造者與構(gòu)造對象的關(guān)系；構(gòu)造的方式；聚合與合成； （3）服務(wù)提供者：主動告知，被動告知；獨立的行為；提供有業(yè)務(wù)價值的行為； （4）協(xié)調(diào)者：如何委派和轉(zhuǎn)發(fā)請求；如何通知其他對象要做的工作；如何通知狀態(tài)的變化； （5）控制者：控制者與被控制者的關(guān)系；控制的決策與邏輯；驅(qū)動其他對象；收集與決策有關(guān)的信息； （6）案例：處理HTTP請求與應(yīng)答，體現(xiàn)信息持有者角色；JMS對Queue的創(chuàng)建體現(xiàn)構(gòu)造者角色；稅務(wù)報告的生成體現(xiàn)服務(wù)提供者角色；服務(wù)定位器體現(xiàn)協(xié)調(diào)者角色；內(nèi)容驗證器體現(xiàn)控制者角色； 4、職責(zé)與封裝的關(guān)系 缺乏合理的封裝，就會缺少正確的領(lǐng)域?qū)ο?，從而?dǎo)致領(lǐng)域信息散亂分布到系統(tǒng)各個方法，使得概念不夠清晰，導(dǎo)致職責(zé)混亂。 5、模塊級的職責(zé)分配 （1）問題分析：模塊之間職責(zé)的分配，在面臨三種問題時，應(yīng)該如何應(yīng)對？通過對具體問題的分析，討論模塊之間的職責(zé)分配，以及對高內(nèi)聚、松耦合的理解。同時，該問題分析還將引入Template Method模式； （2）問題分析：錯誤的職責(zé)分配帶來的循環(huán)依賴問題，以及對包的復(fù)用原則的違背，提出解決辦法； （3）模塊重用：對eBay模塊的分析，以及對某大型系統(tǒng)架構(gòu)的演進，提出模塊重用的方式； 6、原則與模式 （1）單一職責(zé)原則：分析該原則的核心思想，關(guān)注對象的變化點； （2）案例分析：功能引擎中對功能對象的加載，如何體現(xiàn)職責(zé)分離帶來的好處；通過對案例分析引入Proxy模式； （3）專家模式：專家模式的核心思想是信息的持有者是操作該信息的專家； （4）案例分析：報表參數(shù)的處理方式，如何通過識別設(shè)計違背了專家模式，并依據(jù)專家模式對設(shè)計進行改進，從而巧妙地利用多態(tài)消除代碼壞味道，并進而通過引入Adapter模式處理模塊之間的依賴關(guān)系； （5）自治對象：分析了自治對象的特征，分別包括：最小完備，穩(wěn)定空間，自我履行與獨立進化。 （6）案例分析：用戶狀態(tài)機，給出了某金融系統(tǒng)中復(fù)雜的用戶狀態(tài)遷移，體現(xiàn)的復(fù)雜授權(quán)、登錄等業(yè)務(wù)邏輯，并由此引入State模式來簡化設(shè)計，體現(xiàn)自治對象的特征。 |
|
第二單元 面向?qū)ο笤O(shè)計： 抽象與變化 擴展式設(shè)計 |
合理的職責(zé)分配并不能完全保證軟件設(shè)計的卓越，因為需求變化是軟件開發(fā)的常態(tài)，因此設(shè)計必須在一定程度滿足變化，保證系統(tǒng)的可擴展性。 1、抽象的意義 抽象的關(guān)鍵在于尋找多個對象（或行為）具有的共同特征，并對特性進行泛化。泛化的特征可以暴露在外，從而隔離內(nèi)部的實現(xiàn)。 （1）用例分析：對用例和參與者的泛化；遵循的原則； （2）案例分析：授權(quán)框架的設(shè)計，體現(xiàn)了對共同特征的提取，合理引入Chain Of Responsibility模式與Template Method模式； （3）案例分析：項目管理模型的抽象，通過對多種項目管理過程進行分析，對各種模型概念進行分類，并抽象出模型的共同特征，從而簡化模型； 2、識別變化 要保證設(shè)計的可擴展性，主要過程是識別變化點，然后對變化進行封裝。 （1）變化點：常見的變化點包括業(yè)務(wù)規(guī)則、算法策略、外部服務(wù)、硬件支持、命令請求、協(xié)議標(biāo)準(zhǔn)、數(shù)據(jù)格式、業(yè)務(wù)流程、系統(tǒng)配置、界面表現(xiàn)； （2）案例分析：電子商務(wù)系統(tǒng)的Invoice業(yè)務(wù)規(guī)則，引入Specification模式；CIMS系統(tǒng)的機器加載策略，引入Strategy模式；短信服務(wù)，引入Facade模式與Adapter模式；人力資源系統(tǒng)考勤模塊，引入Gateway模式； （3）案例分析：CQRS框架，對命令處理邏輯的包裝，引入Decorator模式，并通過分析變化點，引入另一種替代Decorator模式的設(shè)計。 3、依賴解耦 處理變化的關(guān)鍵是要解除對具體對象的依賴。 （1）表驅(qū)動法 （2）配置與反射 （3）IoC容器 （4）慣例優(yōu)于配置 4、擴展式設(shè)計 擴展式設(shè)計分為三個步驟，分別為：分離職責(zé)各司其職，利用抽象統(tǒng)一接口，引用接口預(yù)留空白。擴展式設(shè)計可以有效地保證整個系統(tǒng)的可擴展性。 （1）擴展式設(shè)計的步驟 （2）實戰(zhàn)演練：訂單處理，通過三次迭代逐步改進原有設(shè)計，并分別遵循專家模式、分離原則與擴展式設(shè)計，保證設(shè)計在修改最小的前提下滿足需求變化。在設(shè)計演進中，討論對設(shè)計模式的合理運用，并引入Specification模式； （3）案例分析：配置管理框架的設(shè)計，該框架能夠支持配置信息的多種存儲形態(tài)，包括文件、數(shù)據(jù)庫、LDAP等；支持多種獲取配置的方式，如Web服務(wù)，REST服務(wù)。配置管理框架的接口需要保證其統(tǒng)一性和一致性，同時在滿足可擴展要求下，提供接口的易用性。 （4）案例分析：消息隊列規(guī)范的設(shè)計。通過分析JMS、MSMQ、RabbitMQ和NServiceBus的設(shè)計，理解抽象的含義，例如理解面向接口設(shè)計、接口隔離原則、按意圖設(shè)計、Facade模式與企業(yè)集成模式。 （5）實戰(zhàn)演練：CIMS基于消息的分布式架構(gòu)。通過對服務(wù)的統(tǒng)一抽象，以及對消息處理的職責(zé)分配，建立一個協(xié)作合理的分布式架構(gòu)。設(shè)計過程中會引入Command模式、Publisher – Subscriber模式、Message Bus模式、Message Translator模式、Lookup模式。 |
|
第三單元 場景驅(qū)動設(shè)計： 利用場景建模 設(shè)計過程 |
無論進行怎樣的設(shè)計，都不能離開具體的場景。場景驅(qū)動設(shè)計的要義是基于場景有針對性地進行設(shè)計。場景既是設(shè)計的驅(qū)動力，又是設(shè)計的約束，從而獲得恰如其分的設(shè)計。 1、場景的目標(biāo)層次 （1）概要目標(biāo)：系統(tǒng)層次的場景劃分，每個概要目標(biāo)可對應(yīng)子系統(tǒng)的需求目標(biāo)。通過概要目標(biāo)引入領(lǐng)域驅(qū)動設(shè)計的Unbounded Context。 （2）用戶目標(biāo)：業(yè)務(wù)層次的場景劃分，每個用戶目標(biāo)對應(yīng)各個子系統(tǒng)所提供的業(yè)務(wù)價值，并以服務(wù)的形式暴露給調(diào)用者。 （3）子功能：功能層次的場景劃分，每個子功能都對應(yīng)于業(yè)務(wù)功能，并以領(lǐng)域?qū)ο蠡驒M切關(guān)注點的方式，由服務(wù)調(diào)用。 （4）案例分析：電子商務(wù)系統(tǒng)的場景目標(biāo)劃分，以層次模型的方式表現(xiàn)場景。 2、場景的6W模型 （1）6W的內(nèi)容：分別為who（對應(yīng)于角色）、why（對應(yīng)于業(yè)務(wù)價值）、when（對應(yīng)于對象的協(xié)作）、what（對應(yīng)于業(yè)務(wù)功能）、where（對應(yīng)于場景邊界）和hoW（對應(yīng)于業(yè)務(wù)實現(xiàn)）； （2）6W模型的設(shè)計驅(qū)動力：6W模型的關(guān)鍵是在場景邊界內(nèi)，通過場景識別出角色，再以角色為設(shè)計入口，運用職責(zé)的層次模型識別出業(yè)務(wù)價值、業(yè)務(wù)功能和業(yè)務(wù)實現(xiàn)，從而根據(jù)職責(zé)模型獲得領(lǐng)域模型，再通過時序圖，處理對象之間的協(xié)作關(guān)系，進一步精煉出更為準(zhǔn)確的領(lǐng)域模型。 3、場景驅(qū)動設(shè)計演練 （1）實戰(zhàn)案例：某大型跨國公司的內(nèi)部培訓(xùn)系統(tǒng)，包括培訓(xùn)計劃制訂，培訓(xùn)實施以及員工職業(yè)生涯規(guī)劃等功能； （2）對整個系統(tǒng)進行分析，識別場景的目標(biāo)層次； （3）劃分需求場景，運用6W模型進行場景驅(qū)動設(shè)計； 場景一：將培訓(xùn)的Ticket分配給員工。在分配ticket時，需要指定deadline，以及取消票或deadline到期時的Action。同時，將該ticket的狀態(tài)設(shè)置為pending； 場景二：在接收到分配ticket的通知后，并在設(shè)定的deadline之前，拒絕該ticket。此時，會自動執(zhí)行事先分配給ticket的取消票的action； 場景三：根據(jù)設(shè)定的trigger周期，定期掃描在當(dāng)日滿足deadline條件的ticket；如果存在滿足deadline條件的ticket，且ticket的狀態(tài)不為accepted，則需要觸發(fā)事先指定給該ticket的action。 場景四：無論是nomination，還是接收ticket、取消ticket，或者deadline以及取消執(zhí)行的action，只要是對ticket進行了處理，都需要記錄這次處理ticket的記錄，以便于未來對該票的跟蹤； 整個演練將完整介紹場景驅(qū)動設(shè)計的過程，并結(jié)合前面講解的職責(zé)驅(qū)動設(shè)計與擴展式設(shè)計，確保優(yōu)良的設(shè)計。案例會引入對領(lǐng)域建模的考量，識別職責(zé)、識別變化點并封裝變化。設(shè)計會引入Strategy模式，Bridge模式、Repository模式、State模式以及Interceptor模式等，使設(shè)計滿足可重用性、可擴展性。 4、卓越的軟件設(shè)計 整個設(shè)計過程是由場景來驅(qū)動，通過角色識別職責(zé)，然后遵循高內(nèi)聚原則對對象進行封裝。合理的封裝還必須保證對象之間的協(xié)作是松耦合。其中，可通過識別變化點，利用抽象對變化進行封裝。卓越的軟件設(shè)計還需要不斷地演進，保證設(shè)計達到卓越的途徑是識別壞味道，然后通過重構(gòu)對代碼進行改進；還可以運用探索式設(shè)計，對職責(zé)進行合理的分配。 （1）常見的壞味道：包括過長方法、過大的類、特性依戀、霰彈式修改、消息鏈、并行的繼承體系、中間人等； （2）探索式方法：包括方法分組、觀察隱藏方法、尋找可以更改的決定、尋找內(nèi)部關(guān)系、尋找主要職責(zé)、草稿式重構(gòu)與關(guān)注當(dāng)前工作。 （3）卓越軟件設(shè)計模型 |
|
第一單元： 面向?qū)ο笤O(shè)計： 角色、職責(zé)與協(xié)作 職責(zé)驅(qū)動設(shè)計 面向?qū)ο笤O(shè)計的核心驅(qū)動力是對象的職責(zé)，合理的職責(zé)分配是卓越軟件設(shè)計的前提。只有合理地分辨對象的職責(zé)，才能夠定義良好的對象，并實現(xiàn)符合系統(tǒng)一致性的對象協(xié)作關(guān)系。 1、職責(zé)的層次 通過職責(zé)層次模型對需求進行分析，識別出業(yè)務(wù)價值、業(yè)務(wù)功能與業(yè)務(wù)實現(xiàn)。職責(zé)層次的分解可以有效地幫助設(shè)計者辨別職責(zé)。 （1）職責(zé)層次的識別 （2）職責(zé)層次與軟件架構(gòu)層次之間的關(guān)系 （3）職責(zé)與概念、規(guī)約與實現(xiàn) （4）案例分析：分析郵件服務(wù)器代碼暴露的問題，在可重用性、代碼可維護性、可擴展性等諸多方面著手，剖析代碼壞味道。通過分辨職責(zé)層次，來改善設(shè)計。并提出需求變更，從而引入對Observer模式、Strategy模式、Simple Factory模式、Mediator模式與Chain Of Responsibility模式的對比與分析； （5）實戰(zhàn)演練：設(shè)計一個作業(yè)調(diào)度框架，它能夠根據(jù)指定的時間觸發(fā)作業(yè)，執(zhí)行自定義任務(wù)。 2、職責(zé)的分類 職責(zé)并不等于功能，也不等同于行為或方法。分析職責(zé)，應(yīng)從對象的認知與行為入手。 3、對象的角色 角色、職責(zé)與協(xié)作是三位一體的關(guān)系，角色是發(fā)起職責(zé)的對象，職責(zé)則應(yīng)該是對象之間的協(xié)作。不同角色的對象，履行的職責(zé)是不同的。 （1）信息持有者：信息的格式；是否需要持久化；信息源的改變，是否需要更新；處理信息的方式； （2）構(gòu)造者：構(gòu)造者與構(gòu)造對象的關(guān)系；構(gòu)造的方式；聚合與合成； （3）服務(wù)提供者：主動告知，被動告知；獨立的行為；提供有業(yè)務(wù)價值的行為； （4）協(xié)調(diào)者：如何委派和轉(zhuǎn)發(fā)請求；如何通知其他對象要做的工作；如何通知狀態(tài)的變化； （5）控制者：控制者與被控制者的關(guān)系；控制的決策與邏輯；驅(qū)動其他對象；收集與決策有關(guān)的信息； （6）案例：處理HTTP請求與應(yīng)答，體現(xiàn)信息持有者角色；JMS對Queue的創(chuàng)建體現(xiàn)構(gòu)造者角色；稅務(wù)報告的生成體現(xiàn)服務(wù)提供者角色；服務(wù)定位器體現(xiàn)協(xié)調(diào)者角色；內(nèi)容驗證器體現(xiàn)控制者角色； 4、職責(zé)與封裝的關(guān)系 缺乏合理的封裝，就會缺少正確的領(lǐng)域?qū)ο?，從而?dǎo)致領(lǐng)域信息散亂分布到系統(tǒng)各個方法，使得概念不夠清晰，導(dǎo)致職責(zé)混亂。 5、模塊級的職責(zé)分配 （1）問題分析：模塊之間職責(zé)的分配，在面臨三種問題時，應(yīng)該如何應(yīng)對？通過對具體問題的分析，討論模塊之間的職責(zé)分配，以及對高內(nèi)聚、松耦合的理解。同時，該問題分析還將引入Template Method模式； （2）問題分析：錯誤的職責(zé)分配帶來的循環(huán)依賴問題，以及對包的復(fù)用原則的違背，提出解決辦法； （3）模塊重用：對eBay模塊的分析，以及對某大型系統(tǒng)架構(gòu)的演進，提出模塊重用的方式； 6、原則與模式 （1）單一職責(zé)原則：分析該原則的核心思想，關(guān)注對象的變化點； （2）案例分析：功能引擎中對功能對象的加載，如何體現(xiàn)職責(zé)分離帶來的好處；通過對案例分析引入Proxy模式； （3）專家模式：專家模式的核心思想是信息的持有者是操作該信息的專家； （4）案例分析：報表參數(shù)的處理方式，如何通過識別設(shè)計違背了專家模式，并依據(jù)專家模式對設(shè)計進行改進，從而巧妙地利用多態(tài)消除代碼壞味道，并進而通過引入Adapter模式處理模塊之間的依賴關(guān)系； （5）自治對象：分析了自治對象的特征，分別包括：最小完備，穩(wěn)定空間，自我履行與獨立進化。 （6）案例分析：用戶狀態(tài)機，給出了某金融系統(tǒng)中復(fù)雜的用戶狀態(tài)遷移，體現(xiàn)的復(fù)雜授權(quán)、登錄等業(yè)務(wù)邏輯，并由此引入State模式來簡化設(shè)計，體現(xiàn)自治對象的特征。 |
|
第二單元 面向?qū)ο笤O(shè)計： 抽象與變化 擴展式設(shè)計 合理的職責(zé)分配并不能完全保證軟件設(shè)計的卓越，因為需求變化是軟件開發(fā)的常態(tài)，因此設(shè)計必須在一定程度滿足變化，保證系統(tǒng)的可擴展性。 1、抽象的意義 抽象的關(guān)鍵在于尋找多個對象（或行為）具有的共同特征，并對特性進行泛化。泛化的特征可以暴露在外，從而隔離內(nèi)部的實現(xiàn)。 （1）用例分析：對用例和參與者的泛化；遵循的原則； （2）案例分析：授權(quán)框架的設(shè)計，體現(xiàn)了對共同特征的提取，合理引入Chain Of Responsibility模式與Template Method模式； （3）案例分析：項目管理模型的抽象，通過對多種項目管理過程進行分析，對各種模型概念進行分類，并抽象出模型的共同特征，從而簡化模型； 2、識別變化 要保證設(shè)計的可擴展性，主要過程是識別變化點，然后對變化進行封裝。 （1）變化點：常見的變化點包括業(yè)務(wù)規(guī)則、算法策略、外部服務(wù)、硬件支持、命令請求、協(xié)議標(biāo)準(zhǔn)、數(shù)據(jù)格式、業(yè)務(wù)流程、系統(tǒng)配置、界面表現(xiàn)； （2）案例分析：電子商務(wù)系統(tǒng)的Invoice業(yè)務(wù)規(guī)則，引入Specification模式；CIMS系統(tǒng)的機器加載策略，引入Strategy模式；短信服務(wù)，引入Facade模式與Adapter模式；人力資源系統(tǒng)考勤模塊，引入Gateway模式； （3）案例分析：CQRS框架，對命令處理邏輯的包裝，引入Decorator模式，并通過分析變化點，引入另一種替代Decorator模式的設(shè)計。 3、依賴解耦 處理變化的關(guān)鍵是要解除對具體對象的依賴。 （1）表驅(qū)動法 （2）配置與反射 （3）IoC容器 （4）慣例優(yōu)于配置 4、擴展式設(shè)計 擴展式設(shè)計分為三個步驟，分別為：分離職責(zé)各司其職，利用抽象統(tǒng)一接口，引用接口預(yù)留空白。擴展式設(shè)計可以有效地保證整個系統(tǒng)的可擴展性。 （1）擴展式設(shè)計的步驟 （2）實戰(zhàn)演練：訂單處理，通過三次迭代逐步改進原有設(shè)計，并分別遵循專家模式、分離原則與擴展式設(shè)計，保證設(shè)計在修改最小的前提下滿足需求變化。在設(shè)計演進中，討論對設(shè)計模式的合理運用，并引入Specification模式； （3）案例分析：配置管理框架的設(shè)計，該框架能夠支持配置信息的多種存儲形態(tài)，包括文件、數(shù)據(jù)庫、LDAP等；支持多種獲取配置的方式，如Web服務(wù)，REST服務(wù)。配置管理框架的接口需要保證其統(tǒng)一性和一致性，同時在滿足可擴展要求下，提供接口的易用性。 （4）案例分析：消息隊列規(guī)范的設(shè)計。通過分析JMS、MSMQ、RabbitMQ和NServiceBus的設(shè)計，理解抽象的含義，例如理解面向接口設(shè)計、接口隔離原則、按意圖設(shè)計、Facade模式與企業(yè)集成模式。 （5）實戰(zhàn)演練：CIMS基于消息的分布式架構(gòu)。通過對服務(wù)的統(tǒng)一抽象，以及對消息處理的職責(zé)分配，建立一個協(xié)作合理的分布式架構(gòu)。設(shè)計過程中會引入Command模式、Publisher – Subscriber模式、Message Bus模式、Message Translator模式、Lookup模式。 |
|
第三單元 場景驅(qū)動設(shè)計： 利用場景建模 設(shè)計過程 無論進行怎樣的設(shè)計，都不能離開具體的場景。場景驅(qū)動設(shè)計的要義是基于場景有針對性地進行設(shè)計。場景既是設(shè)計的驅(qū)動力，又是設(shè)計的約束，從而獲得恰如其分的設(shè)計。 1、場景的目標(biāo)層次 （1）概要目標(biāo)：系統(tǒng)層次的場景劃分，每個概要目標(biāo)可對應(yīng)子系統(tǒng)的需求目標(biāo)。通過概要目標(biāo)引入領(lǐng)域驅(qū)動設(shè)計的Unbounded Context。 （2）用戶目標(biāo)：業(yè)務(wù)層次的場景劃分，每個用戶目標(biāo)對應(yīng)各個子系統(tǒng)所提供的業(yè)務(wù)價值，并以服務(wù)的形式暴露給調(diào)用者。 （3）子功能：功能層次的場景劃分，每個子功能都對應(yīng)于業(yè)務(wù)功能，并以領(lǐng)域?qū)ο蠡驒M切關(guān)注點的方式，由服務(wù)調(diào)用。 （4）案例分析：電子商務(wù)系統(tǒng)的場景目標(biāo)劃分，以層次模型的方式表現(xiàn)場景。 2、場景的6W模型 （1）6W的內(nèi)容：分別為who（對應(yīng)于角色）、why（對應(yīng)于業(yè)務(wù)價值）、when（對應(yīng)于對象的協(xié)作）、what（對應(yīng)于業(yè)務(wù)功能）、where（對應(yīng)于場景邊界）和hoW（對應(yīng)于業(yè)務(wù)實現(xiàn)）； （2）6W模型的設(shè)計驅(qū)動力：6W模型的關(guān)鍵是在場景邊界內(nèi)，通過場景識別出角色，再以角色為設(shè)計入口，運用職責(zé)的層次模型識別出業(yè)務(wù)價值、業(yè)務(wù)功能和業(yè)務(wù)實現(xiàn)，從而根據(jù)職責(zé)模型獲得領(lǐng)域模型，再通過時序圖，處理對象之間的協(xié)作關(guān)系，進一步精煉出更為準(zhǔn)確的領(lǐng)域模型。 3、場景驅(qū)動設(shè)計演練 （1）實戰(zhàn)案例：某大型跨國公司的內(nèi)部培訓(xùn)系統(tǒng)，包括培訓(xùn)計劃制訂，培訓(xùn)實施以及員工職業(yè)生涯規(guī)劃等功能； （2）對整個系統(tǒng)進行分析，識別場景的目標(biāo)層次； （3）劃分需求場景，運用6W模型進行場景驅(qū)動設(shè)計； 場景一：將培訓(xùn)的Ticket分配給員工。在分配ticket時，需要指定deadline，以及取消票或deadline到期時的Action。同時，將該ticket的狀態(tài)設(shè)置為pending； 場景二：在接收到分配ticket的通知后，并在設(shè)定的deadline之前，拒絕該ticket。此時，會自動執(zhí)行事先分配給ticket的取消票的action； 場景三：根據(jù)設(shè)定的trigger周期，定期掃描在當(dāng)日滿足deadline條件的ticket；如果存在滿足deadline條件的ticket，且ticket的狀態(tài)不為accepted，則需要觸發(fā)事先指定給該ticket的action。 場景四：無論是nomination，還是接收ticket、取消ticket，或者deadline以及取消執(zhí)行的action，只要是對ticket進行了處理，都需要記錄這次處理ticket的記錄，以便于未來對該票的跟蹤； 整個演練將完整介紹場景驅(qū)動設(shè)計的過程，并結(jié)合前面講解的職責(zé)驅(qū)動設(shè)計與擴展式設(shè)計，確保優(yōu)良的設(shè)計。案例會引入對領(lǐng)域建模的考量，識別職責(zé)、識別變化點并封裝變化。設(shè)計會引入Strategy模式，Bridge模式、Repository模式、State模式以及Interceptor模式等，使設(shè)計滿足可重用性、可擴展性。 4、卓越的軟件設(shè)計 整個設(shè)計過程是由場景來驅(qū)動，通過角色識別職責(zé)，然后遵循高內(nèi)聚原則對對象進行封裝。合理的封裝還必須保證對象之間的協(xié)作是松耦合。其中，可通過識別變化點，利用抽象對變化進行封裝。卓越的軟件設(shè)計還需要不斷地演進，保證設(shè)計達到卓越的途徑是識別壞味道，然后通過重構(gòu)對代碼進行改進；還可以運用探索式設(shè)計，對職責(zé)進行合理的分配。 （1）常見的壞味道：包括過長方法、過大的類、特性依戀、霰彈式修改、消息鏈、并行的繼承體系、中間人等； （2）探索式方法：包括方法分組、觀察隱藏方法、尋找可以更改的決定、尋找內(nèi)部關(guān)系、尋找主要職責(zé)、草稿式重構(gòu)與關(guān)注當(dāng)前工作。 （3）卓越軟件設(shè)計模型 |
近期公開課推薦
