開發(fā)經理
其他
軟件設計
推薦課程
average > 0 ? $model->average . '分' : '10.0分' ?>

卓越軟件設計匠藝

Bruce Zhang

前ThoughtWorks 架構師、敏捷教練

先后就職于中興通訊、惠普 GDCC、中軟國際、ThoughtWorks 等?大型中外企
業(yè),任職?角?色為?高級軟件?工程師,架構師,技術總監(jiān),?首席咨詢師?,F為深圳?
大眼科技有限公司的?首席架構師,聯合創(chuàng)始?人。精通包括 C#、Java、Ruby、Scala、
Python、JavaScript 等多種語?言,熟練掌握?面向對象思想、領域驅動設計、函數式語
?言、架構、?大數據分析、敏捷與過程改進,并致?力于?大型軟件企業(yè)的?面向服務系
統(tǒng)架構設計以及互聯網 Web 系統(tǒng)架構設計。在 ThoughtWorks 期間,作為?一名咨詢師,
主要為客戶提供組織的敏捷轉型、過程改進、系統(tǒng)架構監(jiān)理、領域設計、代碼質量提升等咨
詢?工作。目前,作為公司產品的架構師,致力于商業(yè)智能產品與?大數據分析平臺的開發(fā)
與架構設計

著譯作包括《解構領域驅動設計》、《軟件設計精要與模式》、《架構寶典》、《高可用可伸縮微服務架構》、《Java設計模式》、《恰如其分的軟件架構》、《WCF服務編程》、《人件》、《重構——改善既有代碼設計》評注版、《架構之美》評注版。

作為主持?人或講師多次被應邀參加如中國軟件?大會、QCon、MPD 大會、
Agile China、Scrum Gathering 等?大型會議,并作為培訓講師曾先后為摩托羅拉、惠普、
花旗銀?行、攜程、TCL、中興通訊、賽 門鐵克,廣發(fā)證券、平安銀?行等企業(yè)培訓架構、
設計、DDD、敏捷等專題內容。著譯作包括《軟件設計精要與模式》、《Java 設計模式》、《恰如其分的軟件架構》、《WCF 服務編程》、《?人件》等。目前,正在撰寫《架構之
美(Beatiful Architecture)》評注版,即將出版。

先后就職于中興通訊、惠普 GDCC、中軟國際、ThoughtWorks 等?大型中外企 業(yè),任職?角?色為?高級軟件?工程師,架構師,技術總監(jiān),?首席咨詢師?,F為深圳? 大眼科技有限公司的?首席架構師,聯合創(chuàng)始?人。精通包括 C#、Java、Ruby、Scala、 Python、JavaScript 等多種語?言,熟練掌握?面向對象思想、領域驅動設計、函數式語 ?言、架構、?大數據分析、敏捷與過程改進,并致?力于?大型軟件企業(yè)的?面向服務系 統(tǒng)架構設計以及互聯網 Web 系統(tǒng)架構設計。在 ThoughtWorks 期間,作為?一名咨詢師, 主要為客戶提供組織的敏捷轉型、過程改進、系統(tǒng)架構監(jiān)理、領域設計、代碼質量提升等咨 詢?工作。目前,作為公司產品的架構師,致力于商業(yè)智能產品與?大數據分析平臺的開發(fā) 與架構設計 著譯作包括《解構領域驅動設計》、《軟件設計精要與模式》、《架構寶典》、《高可用可伸縮微服務架構》、《Java設計模式》、《恰如其分的軟件架構》、《WCF服務編程》、《人件》、《重構——改善既有代碼設計》評注版、《架構之美》評注版。 作為主持?人或講師多次被應邀參加如中國軟件?大會、QCon、MPD 大會、 Agile China、Scrum Gathering 等?大型會議,并作為培訓講師曾先后為摩托羅拉、惠普、 花旗銀?行、攜程、TCL、中興通訊、賽 門鐵克,廣發(fā)證券、平安銀?行等企業(yè)培訓架構、 設計、DDD、敏捷等專題內容。著譯作包括《軟件設計精要與模式》、《Java 設計模式》、《恰如其分的軟件架構》、《WCF 服務編程》、《?人件》等。目前,正在撰寫《架構之 美(Beatiful Architecture)》評注版,即將出版。

課程費用

5800.00 /人

課程時長

2

成為教練

課程簡介

1、全真案例,借助案例與設計模式知識的原理,借助最佳實踐,幫助您提高設計能力,從而提高開發(fā)效率和設計質量
2、以新視角,揭示模式的本質、思想方法,剖析出模式之“道”,跳出“為模式而模式”的“陷阱”
3、提升設計能力,使開發(fā)人員由“編程小工”到設計專家
4、提出場景驅動設計,利用領域建模、職責驅動、擴展式設計以及重構,提高軟件設計質量,實現卓越軟件設計
5、關注業(yè)界內設計模式,以實戰(zhàn)訓練驅動對面向對象設計的理解與運用

目標收益

1、員工無法接手遺留系統(tǒng),原因是代碼雜亂,可讀性差
2、團隊成員沒有設計模式知識與經驗,無法實施敏捷開發(fā)
3、系統(tǒng)難以重構,不利于產品的重用與二次開發(fā)
4、開發(fā)效率得不到保障,因為詳細設計人員不能理解架構文檔與詳細設計方案
5、設計方案難于應對需求變更
6、設計的系統(tǒng)架構缺乏可擴展性、可維護性和可測試性,不能合理地重用
7、架構、設計、開發(fā)三個環(huán)節(jié)中各個角色不能理解設計意圖,很難溝通

培訓對象

IT人員

課程大綱

第一單元:
面向對象設計:
角色、職責與協(xié)作
職責驅動設計
面向對象設計的核心驅動力是對象的職責,合理的職責分配是卓越軟件設計的前提。只有合理地分辨對象的職責,才能夠定義良好的對象,并實現符合系統(tǒng)一致性的對象協(xié)作關系。
1、職責的層次
通過職責層次模型對需求進行分析,識別出業(yè)務價值、業(yè)務功能與業(yè)務實現。職責層次的分解可以有效地幫助設計者辨別職責。
(1)職責層次的識別
(2)職責層次與軟件架構層次之間的關系
(3)職責與概念、規(guī)約與實現
(4)案例分析:分析郵件服務器代碼暴露的問題,在可重用性、代碼可維護性、可擴展性等諸多方面著手,剖析代碼壞味道。通過分辨職責層次,來改善設計。并提出需求變更,從而引入對Observer模式、Strategy模式、Simple Factory模式、Mediator模式與Chain Of Responsibility模式的對比與分析;
(5)實戰(zhàn)演練:設計一個作業(yè)調度框架,它能夠根據指定的時間觸發(fā)作業(yè),執(zhí)行自定義任務。

2、職責的分類
職責并不等于功能,也不等同于行為或方法。分析職責,應從對象的認知與行為入手。

3、對象的角色
角色、職責與協(xié)作是三位一體的關系,角色是發(fā)起職責的對象,職責則應該是對象之間的協(xié)作。不同角色的對象,履行的職責是不同的。
(1)信息持有者:信息的格式;是否需要持久化;信息源的改變,是否需要更新;處理信息的方式;
(2)構造者:構造者與構造對象的關系;構造的方式;聚合與合成;
(3)服務提供者:主動告知,被動告知;獨立的行為;提供有業(yè)務價值的行為;
(4)協(xié)調者:如何委派和轉發(fā)請求;如何通知其他對象要做的工作;如何通知狀態(tài)的變化;
(5)控制者:控制者與被控制者的關系;控制的決策與邏輯;驅動其他對象;收集與決策有關的信息;
(6)案例:處理HTTP請求與應答,體現信息持有者角色;JMS對Queue的創(chuàng)建體現構造者角色;稅務報告的生成體現服務提供者角色;服務定位器體現協(xié)調者角色;內容驗證器體現控制者角色;

4、職責與封裝的關系
缺乏合理的封裝,就會缺少正確的領域對象,從而導致領域信息散亂分布到系統(tǒng)各個方法,使得概念不夠清晰,導致職責混亂。

5、模塊級的職責分配
(1)問題分析:模塊之間職責的分配,在面臨三種問題時,應該如何應對?通過對具體問題的分析,討論模塊之間的職責分配,以及對高內聚、松耦合的理解。同時,該問題分析還將引入Template Method模式;
(2)問題分析:錯誤的職責分配帶來的循環(huán)依賴問題,以及對包的復用原則的違背,提出解決辦法;
(3)模塊重用:對eBay模塊的分析,以及對某大型系統(tǒng)架構的演進,提出模塊重用的方式;

6、原則與模式
(1)單一職責原則:分析該原則的核心思想,關注對象的變化點;
(2)案例分析:功能引擎中對功能對象的加載,如何體現職責分離帶來的好處;通過對案例分析引入Proxy模式;
(3)專家模式:專家模式的核心思想是信息的持有者是操作該信息的專家;
(4)案例分析:報表參數的處理方式,如何通過識別設計違背了專家模式,并依據專家模式對設計進行改進,從而巧妙地利用多態(tài)消除代碼壞味道,并進而通過引入Adapter模式處理模塊之間的依賴關系;
(5)自治對象:分析了自治對象的特征,分別包括:最小完備,穩(wěn)定空間,自我履行與獨立進化。
(6)案例分析:用戶狀態(tài)機,給出了某金融系統(tǒng)中復雜的用戶狀態(tài)遷移,體現的復雜授權、登錄等業(yè)務邏輯,并由此引入State模式來簡化設計,體現自治對象的特征。
第二單元
面向對象設計:
抽象與變化
擴展式設計
合理的職責分配并不能完全保證軟件設計的卓越,因為需求變化是軟件開發(fā)的常態(tài),因此設計必須在一定程度滿足變化,保證系統(tǒng)的可擴展性。
1、抽象的意義
抽象的關鍵在于尋找多個對象(或行為)具有的共同特征,并對特性進行泛化。泛化的特征可以暴露在外,從而隔離內部的實現。
(1)用例分析:對用例和參與者的泛化;遵循的原則;
(2)案例分析:授權框架的設計,體現了對共同特征的提取,合理引入Chain Of Responsibility模式與Template Method模式;
(3)案例分析:項目管理模型的抽象,通過對多種項目管理過程進行分析,對各種模型概念進行分類,并抽象出模型的共同特征,從而簡化模型;

2、識別變化
要保證設計的可擴展性,主要過程是識別變化點,然后對變化進行封裝。
(1)變化點:常見的變化點包括業(yè)務規(guī)則、算法策略、外部服務、硬件支持、命令請求、協(xié)議標準、數據格式、業(yè)務流程、系統(tǒng)配置、界面表現;
(2)案例分析:電子商務系統(tǒng)的Invoice業(yè)務規(guī)則,引入Specification模式;CIMS系統(tǒng)的機器加載策略,引入Strategy模式;短信服務,引入Facade模式與Adapter模式;人力資源系統(tǒng)考勤模塊,引入Gateway模式;
(3)案例分析:CQRS框架,對命令處理邏輯的包裝,引入Decorator模式,并通過分析變化點,引入另一種替代Decorator模式的設計。

3、依賴解耦
處理變化的關鍵是要解除對具體對象的依賴。
(1)表驅動法
(2)配置與反射
(3)IoC容器
(4)慣例優(yōu)于配置

4、擴展式設計
擴展式設計分為三個步驟,分別為:分離職責各司其職,利用抽象統(tǒng)一接口,引用接口預留空白。擴展式設計可以有效地保證整個系統(tǒng)的可擴展性。
(1)擴展式設計的步驟
(2)實戰(zhàn)演練:訂單處理,通過三次迭代逐步改進原有設計,并分別遵循專家模式、分離原則與擴展式設計,保證設計在修改最小的前提下滿足需求變化。在設計演進中,討論對設計模式的合理運用,并引入Specification模式;
(3)案例分析:配置管理框架的設計,該框架能夠支持配置信息的多種存儲形態(tài),包括文件、數據庫、LDAP等;支持多種獲取配置的方式,如Web服務,REST服務。配置管理框架的接口需要保證其統(tǒng)一性和一致性,同時在滿足可擴展要求下,提供接口的易用性。
(4)案例分析:消息隊列規(guī)范的設計。通過分析JMS、MSMQ、RabbitMQ和NServiceBus的設計,理解抽象的含義,例如理解面向接口設計、接口隔離原則、按意圖設計、Facade模式與企業(yè)集成模式。
(5)實戰(zhàn)演練:CIMS基于消息的分布式架構。通過對服務的統(tǒng)一抽象,以及對消息處理的職責分配,建立一個協(xié)作合理的分布式架構。設計過程中會引入Command模式、Publisher – Subscriber模式、Message Bus模式、Message Translator模式、Lookup模式。
第三單元
場景驅動設計:
利用場景建模
設計過程
無論進行怎樣的設計,都不能離開具體的場景。場景驅動設計的要義是基于場景有針對性地進行設計。場景既是設計的驅動力,又是設計的約束,從而獲得恰如其分的設計。
1、場景的目標層次
(1)概要目標:系統(tǒng)層次的場景劃分,每個概要目標可對應子系統(tǒng)的需求目標。通過概要目標引入領域驅動設計的Unbounded Context。
(2)用戶目標:業(yè)務層次的場景劃分,每個用戶目標對應各個子系統(tǒng)所提供的業(yè)務價值,并以服務的形式暴露給調用者。
(3)子功能:功能層次的場景劃分,每個子功能都對應于業(yè)務功能,并以領域對象或橫切關注點的方式,由服務調用。
(4)案例分析:電子商務系統(tǒng)的場景目標劃分,以層次模型的方式表現場景。

2、場景的6W模型
(1)6W的內容:分別為who(對應于角色)、why(對應于業(yè)務價值)、when(對應于對象的協(xié)作)、what(對應于業(yè)務功能)、where(對應于場景邊界)和hoW(對應于業(yè)務實現);
(2)6W模型的設計驅動力:6W模型的關鍵是在場景邊界內,通過場景識別出角色,再以角色為設計入口,運用職責的層次模型識別出業(yè)務價值、業(yè)務功能和業(yè)務實現,從而根據職責模型獲得領域模型,再通過時序圖,處理對象之間的協(xié)作關系,進一步精煉出更為準確的領域模型。

3、場景驅動設計演練
(1)實戰(zhàn)案例:某大型跨國公司的內部培訓系統(tǒng),包括培訓計劃制訂,培訓實施以及員工職業(yè)生涯規(guī)劃等功能;
(2)對整個系統(tǒng)進行分析,識別場景的目標層次;
(3)劃分需求場景,運用6W模型進行場景驅動設計;
場景一:將培訓的Ticket分配給員工。在分配ticket時,需要指定deadline,以及取消票或deadline到期時的Action。同時,將該ticket的狀態(tài)設置為pending;
場景二:在接收到分配ticket的通知后,并在設定的deadline之前,拒絕該ticket。此時,會自動執(zhí)行事先分配給ticket的取消票的action;
場景三:根據設定的trigger周期,定期掃描在當日滿足deadline條件的ticket;如果存在滿足deadline條件的ticket,且ticket的狀態(tài)不為accepted,則需要觸發(fā)事先指定給該ticket的action。
場景四:無論是nomination,還是接收ticket、取消ticket,或者deadline以及取消執(zhí)行的action,只要是對ticket進行了處理,都需要記錄這次處理ticket的記錄,以便于未來對該票的跟蹤;
整個演練將完整介紹場景驅動設計的過程,并結合前面講解的職責驅動設計與擴展式設計,確保優(yōu)良的設計。案例會引入對領域建模的考量,識別職責、識別變化點并封裝變化。設計會引入Strategy模式,Bridge模式、Repository模式、State模式以及Interceptor模式等,使設計滿足可重用性、可擴展性。

4、卓越的軟件設計
整個設計過程是由場景來驅動,通過角色識別職責,然后遵循高內聚原則對對象進行封裝。合理的封裝還必須保證對象之間的協(xié)作是松耦合。其中,可通過識別變化點,利用抽象對變化進行封裝。卓越的軟件設計還需要不斷地演進,保證設計達到卓越的途徑是識別壞味道,然后通過重構對代碼進行改進;還可以運用探索式設計,對職責進行合理的分配。
(1)常見的壞味道:包括過長方法、過大的類、特性依戀、霰彈式修改、消息鏈、并行的繼承體系、中間人等;
(2)探索式方法:包括方法分組、觀察隱藏方法、尋找可以更改的決定、尋找內部關系、尋找主要職責、草稿式重構與關注當前工作。
(3)卓越軟件設計模型
第一單元:
面向對象設計:
角色、職責與協(xié)作
職責驅動設計
面向對象設計的核心驅動力是對象的職責,合理的職責分配是卓越軟件設計的前提。只有合理地分辨對象的職責,才能夠定義良好的對象,并實現符合系統(tǒng)一致性的對象協(xié)作關系。
1、職責的層次
通過職責層次模型對需求進行分析,識別出業(yè)務價值、業(yè)務功能與業(yè)務實現。職責層次的分解可以有效地幫助設計者辨別職責。
(1)職責層次的識別
(2)職責層次與軟件架構層次之間的關系
(3)職責與概念、規(guī)約與實現
(4)案例分析:分析郵件服務器代碼暴露的問題,在可重用性、代碼可維護性、可擴展性等諸多方面著手,剖析代碼壞味道。通過分辨職責層次,來改善設計。并提出需求變更,從而引入對Observer模式、Strategy模式、Simple Factory模式、Mediator模式與Chain Of Responsibility模式的對比與分析;
(5)實戰(zhàn)演練:設計一個作業(yè)調度框架,它能夠根據指定的時間觸發(fā)作業(yè),執(zhí)行自定義任務。

2、職責的分類
職責并不等于功能,也不等同于行為或方法。分析職責,應從對象的認知與行為入手。

3、對象的角色
角色、職責與協(xié)作是三位一體的關系,角色是發(fā)起職責的對象,職責則應該是對象之間的協(xié)作。不同角色的對象,履行的職責是不同的。
(1)信息持有者:信息的格式;是否需要持久化;信息源的改變,是否需要更新;處理信息的方式;
(2)構造者:構造者與構造對象的關系;構造的方式;聚合與合成;
(3)服務提供者:主動告知,被動告知;獨立的行為;提供有業(yè)務價值的行為;
(4)協(xié)調者:如何委派和轉發(fā)請求;如何通知其他對象要做的工作;如何通知狀態(tài)的變化;
(5)控制者:控制者與被控制者的關系;控制的決策與邏輯;驅動其他對象;收集與決策有關的信息;
(6)案例:處理HTTP請求與應答,體現信息持有者角色;JMS對Queue的創(chuàng)建體現構造者角色;稅務報告的生成體現服務提供者角色;服務定位器體現協(xié)調者角色;內容驗證器體現控制者角色;

4、職責與封裝的關系
缺乏合理的封裝,就會缺少正確的領域對象,從而導致領域信息散亂分布到系統(tǒng)各個方法,使得概念不夠清晰,導致職責混亂。

5、模塊級的職責分配
(1)問題分析:模塊之間職責的分配,在面臨三種問題時,應該如何應對?通過對具體問題的分析,討論模塊之間的職責分配,以及對高內聚、松耦合的理解。同時,該問題分析還將引入Template Method模式;
(2)問題分析:錯誤的職責分配帶來的循環(huán)依賴問題,以及對包的復用原則的違背,提出解決辦法;
(3)模塊重用:對eBay模塊的分析,以及對某大型系統(tǒng)架構的演進,提出模塊重用的方式;

6、原則與模式
(1)單一職責原則:分析該原則的核心思想,關注對象的變化點;
(2)案例分析:功能引擎中對功能對象的加載,如何體現職責分離帶來的好處;通過對案例分析引入Proxy模式;
(3)專家模式:專家模式的核心思想是信息的持有者是操作該信息的專家;
(4)案例分析:報表參數的處理方式,如何通過識別設計違背了專家模式,并依據專家模式對設計進行改進,從而巧妙地利用多態(tài)消除代碼壞味道,并進而通過引入Adapter模式處理模塊之間的依賴關系;
(5)自治對象:分析了自治對象的特征,分別包括:最小完備,穩(wěn)定空間,自我履行與獨立進化。
(6)案例分析:用戶狀態(tài)機,給出了某金融系統(tǒng)中復雜的用戶狀態(tài)遷移,體現的復雜授權、登錄等業(yè)務邏輯,并由此引入State模式來簡化設計,體現自治對象的特征。
第二單元
面向對象設計:
抽象與變化
擴展式設計
合理的職責分配并不能完全保證軟件設計的卓越,因為需求變化是軟件開發(fā)的常態(tài),因此設計必須在一定程度滿足變化,保證系統(tǒng)的可擴展性。
1、抽象的意義
抽象的關鍵在于尋找多個對象(或行為)具有的共同特征,并對特性進行泛化。泛化的特征可以暴露在外,從而隔離內部的實現。
(1)用例分析:對用例和參與者的泛化;遵循的原則;
(2)案例分析:授權框架的設計,體現了對共同特征的提取,合理引入Chain Of Responsibility模式與Template Method模式;
(3)案例分析:項目管理模型的抽象,通過對多種項目管理過程進行分析,對各種模型概念進行分類,并抽象出模型的共同特征,從而簡化模型;

2、識別變化
要保證設計的可擴展性,主要過程是識別變化點,然后對變化進行封裝。
(1)變化點:常見的變化點包括業(yè)務規(guī)則、算法策略、外部服務、硬件支持、命令請求、協(xié)議標準、數據格式、業(yè)務流程、系統(tǒng)配置、界面表現;
(2)案例分析:電子商務系統(tǒng)的Invoice業(yè)務規(guī)則,引入Specification模式;CIMS系統(tǒng)的機器加載策略,引入Strategy模式;短信服務,引入Facade模式與Adapter模式;人力資源系統(tǒng)考勤模塊,引入Gateway模式;
(3)案例分析:CQRS框架,對命令處理邏輯的包裝,引入Decorator模式,并通過分析變化點,引入另一種替代Decorator模式的設計。

3、依賴解耦
處理變化的關鍵是要解除對具體對象的依賴。
(1)表驅動法
(2)配置與反射
(3)IoC容器
(4)慣例優(yōu)于配置

4、擴展式設計
擴展式設計分為三個步驟,分別為:分離職責各司其職,利用抽象統(tǒng)一接口,引用接口預留空白。擴展式設計可以有效地保證整個系統(tǒng)的可擴展性。
(1)擴展式設計的步驟
(2)實戰(zhàn)演練:訂單處理,通過三次迭代逐步改進原有設計,并分別遵循專家模式、分離原則與擴展式設計,保證設計在修改最小的前提下滿足需求變化。在設計演進中,討論對設計模式的合理運用,并引入Specification模式;
(3)案例分析:配置管理框架的設計,該框架能夠支持配置信息的多種存儲形態(tài),包括文件、數據庫、LDAP等;支持多種獲取配置的方式,如Web服務,REST服務。配置管理框架的接口需要保證其統(tǒng)一性和一致性,同時在滿足可擴展要求下,提供接口的易用性。
(4)案例分析:消息隊列規(guī)范的設計。通過分析JMS、MSMQ、RabbitMQ和NServiceBus的設計,理解抽象的含義,例如理解面向接口設計、接口隔離原則、按意圖設計、Facade模式與企業(yè)集成模式。
(5)實戰(zhàn)演練:CIMS基于消息的分布式架構。通過對服務的統(tǒng)一抽象,以及對消息處理的職責分配,建立一個協(xié)作合理的分布式架構。設計過程中會引入Command模式、Publisher – Subscriber模式、Message Bus模式、Message Translator模式、Lookup模式。
第三單元
場景驅動設計:
利用場景建模
設計過程
無論進行怎樣的設計,都不能離開具體的場景。場景驅動設計的要義是基于場景有針對性地進行設計。場景既是設計的驅動力,又是設計的約束,從而獲得恰如其分的設計。
1、場景的目標層次
(1)概要目標:系統(tǒng)層次的場景劃分,每個概要目標可對應子系統(tǒng)的需求目標。通過概要目標引入領域驅動設計的Unbounded Context。
(2)用戶目標:業(yè)務層次的場景劃分,每個用戶目標對應各個子系統(tǒng)所提供的業(yè)務價值,并以服務的形式暴露給調用者。
(3)子功能:功能層次的場景劃分,每個子功能都對應于業(yè)務功能,并以領域對象或橫切關注點的方式,由服務調用。
(4)案例分析:電子商務系統(tǒng)的場景目標劃分,以層次模型的方式表現場景。

2、場景的6W模型
(1)6W的內容:分別為who(對應于角色)、why(對應于業(yè)務價值)、when(對應于對象的協(xié)作)、what(對應于業(yè)務功能)、where(對應于場景邊界)和hoW(對應于業(yè)務實現);
(2)6W模型的設計驅動力:6W模型的關鍵是在場景邊界內,通過場景識別出角色,再以角色為設計入口,運用職責的層次模型識別出業(yè)務價值、業(yè)務功能和業(yè)務實現,從而根據職責模型獲得領域模型,再通過時序圖,處理對象之間的協(xié)作關系,進一步精煉出更為準確的領域模型。

3、場景驅動設計演練
(1)實戰(zhàn)案例:某大型跨國公司的內部培訓系統(tǒng),包括培訓計劃制訂,培訓實施以及員工職業(yè)生涯規(guī)劃等功能;
(2)對整個系統(tǒng)進行分析,識別場景的目標層次;
(3)劃分需求場景,運用6W模型進行場景驅動設計;
場景一:將培訓的Ticket分配給員工。在分配ticket時,需要指定deadline,以及取消票或deadline到期時的Action。同時,將該ticket的狀態(tài)設置為pending;
場景二:在接收到分配ticket的通知后,并在設定的deadline之前,拒絕該ticket。此時,會自動執(zhí)行事先分配給ticket的取消票的action;
場景三:根據設定的trigger周期,定期掃描在當日滿足deadline條件的ticket;如果存在滿足deadline條件的ticket,且ticket的狀態(tài)不為accepted,則需要觸發(fā)事先指定給該ticket的action。
場景四:無論是nomination,還是接收ticket、取消ticket,或者deadline以及取消執(zhí)行的action,只要是對ticket進行了處理,都需要記錄這次處理ticket的記錄,以便于未來對該票的跟蹤;
整個演練將完整介紹場景驅動設計的過程,并結合前面講解的職責驅動設計與擴展式設計,確保優(yōu)良的設計。案例會引入對領域建模的考量,識別職責、識別變化點并封裝變化。設計會引入Strategy模式,Bridge模式、Repository模式、State模式以及Interceptor模式等,使設計滿足可重用性、可擴展性。

4、卓越的軟件設計
整個設計過程是由場景來驅動,通過角色識別職責,然后遵循高內聚原則對對象進行封裝。合理的封裝還必須保證對象之間的協(xié)作是松耦合。其中,可通過識別變化點,利用抽象對變化進行封裝。卓越的軟件設計還需要不斷地演進,保證設計達到卓越的途徑是識別壞味道,然后通過重構對代碼進行改進;還可以運用探索式設計,對職責進行合理的分配。
(1)常見的壞味道:包括過長方法、過大的類、特性依戀、霰彈式修改、消息鏈、并行的繼承體系、中間人等;
(2)探索式方法:包括方法分組、觀察隱藏方法、尋找可以更改的決定、尋找內部關系、尋找主要職責、草稿式重構與關注當前工作。
(3)卓越軟件設計模型

課程費用

5800.00 /人

課程時長

2

預約體驗票 我要分享

近期公開課推薦

近期公開課推薦

活動詳情

提交需求