1、培訓過程中，如有部分內容理解不透或消化不好，可免費在以后培訓班中重聽；
        2、培訓結束后,授課老師留給學員聯系方式,保障培訓效果,免費提供課后技術支持。
        3、培訓合格學員可享受免費推薦就業機會。

在課程中要逐一解決的問題：
1、員工無法接手遺留系統，原因是代碼雜亂，可讀性差?
2、團隊成員沒有設計模式知識與經驗，無法實施敏捷開發?
3、系統難以重構，不利于產品的重用與二次開發?
4、開發效率得不到保障，因為詳細設計人員不能理解架構文檔與詳細設計方案?
5、設計方案難于應對需求變更?
6、設計的系統架構缺乏可擴展性、可維護性和可測試性，不能合理地重用
7、架構、設計、開發三個環節中各個角色不能理解設計意圖，很難溝通
內容
第一單元：?
面向對象設計：?
角色、職責與協作
職責驅動設計面向對象設計的核心驅動力是對象的職責，合理的職責分配是卓越軟件設計的前提。只有合理地分辨對象的職責，才能夠定義良好的對象，并實現符合系統一致性的對象協作關系。?
1、職責的層次?
通過職責層次模型對需求進行分析，識別出業務價值、業務功能與業務實現。職責層次的分解可以有效地幫助設計者辨別職責。?
（1）職責層次的識別?
（2）職責層次與軟件架構層次之間的關系?
（3）職責與概念、規約與實現?
（4）案例分析：分析郵件服務器代碼暴露的問題，在可重用性、代碼可維護性、可擴展性等諸多方面著手，剖析代碼壞味道。通過分辨職責層次，來改善設計。并提出需求變更，從而引入對Observer模式、Strategy模式、Simple Factory模式、Mediator模式與Chain Of Responsibility模式的對比與分析；?
（5）實戰演練：設計一個作業調度框架，它能夠根據指定的時間觸發作業，執行自定義任務。

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

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

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

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

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

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

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

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

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

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

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