 班級規模及環境--熱線:4008699035 手機:15921673576( 微信同號) |
|
每期人數限3到5人。 |
| 上課時間和地點 |
上課地點：【上海】：同濟大學(滬西)/新城金郡商務樓(11號線白銀路站) 【深圳分部】：電影大廈(地鐵一號線大劇院站)/深圳大學成教院 【北京分部】：北京中山學院/福鑫大樓 【南京分部】：金港大廈(和燕路) 【武漢分部】：佳源大廈（高新二路） 【成都分部】：領館區1號（中和大道） 【沈陽分部】：沈陽理工大學/六宅臻品 【鄭州分部】：鄭州大學/錦華大廈 【石家莊分部】：河北科技大學/瑞景大廈 【廣州分部】：廣糧大廈 【西安分部】：協同大廈
最近開課時間(周末班/連續班/晚班）：2020年3月16日 |
| 實驗設備 |
☆資深工程師授課
☆注重質量
☆邊講邊練
☆合格學員免費推薦工作
★實驗設備請點擊這兒查看★ |
| 質量保障 |
1、培訓過程中，如有部分內容理解不透或消化不好，可免費在以后培訓班中重聽；
2、培訓結束后,授課老師留給學員聯系方式,保障培訓效果,免費提供課后技術支持。
3、培訓合格學員可享受免費推薦就業機會。 |
課程大綱 |
課程介紹
??
軟件架構并非架構師閉門造車完成的作品，而是整個開發團隊積極與客戶溝通協作，在樹立了共同的系統愿景與目標之后，由架構師基于架構原則與架構方法，在滿足軟件系統功能目標的前提下，進行的一次設計歷險。之所以稱為“歷險”，是因為軟件架構從來都不能一蹴而就，在這個過程中可能會經歷諸多風險和未知的變化，如大海航行可能會遭遇的暗礁與風暴。是否能夠到達成功彼岸，除了需要架構師卓越的架構能力，還需要整個開發團隊遵循系統的架構原則與約束，并能在面對緊急時刻，調整系統的架構方向。
于是，設計軟件架構就面臨兩大難題：
如何明確客戶的需求，并將需求沒有偏差，或較小偏差地轉化為架構？
如何設計恰如其分的架構，從而在不浪費資源的情況下，具有掌控變化與風險的能力？
??
本課程引入的領域驅動設計策略， 正是解決第一個問題的有效方案，它通過一些直觀而又具備協作能力的方式，引導架構師與整個團隊包括客戶積極參與到軟件架構過程中來，并通過場景圖、上下映射圖、六邊形架構等諸多方法與模式，讓架構變成為一種溝通交流的視覺工具。換言之，這是一種體驗式的架構設計。它同樣遵循經典的架構原則與設計方法，但卻可以讓這些原則與方法清晰地可視化，讓團隊協作成為可能，讓架構結果更加直觀，從而避免了溝通上的誤差與分歧，使得團隊能夠迅速就架構內容達成一致。
????
架構本身是復雜的，但它的呈現卻必須足夠清晰簡單，易于理解，因為架構是作為開發團隊交流基礎而存在。要有效地解決前提出的第二個問題，就需要搭建一個具備簡單、一致和自治特色的整潔架構。基于此，整個培訓將圍繞風險驅動設計與 Clean Architecture的思想來指導整個架構過程。
課程核心內容:
本次課程包括以下主要內容：
面向對象分析與設計
領域驅動設計
場景驅動設計
分層架構模式
六邊形架構模式
面向服務架構
基于消息的分布式架構
數據為中心的軟件架構
RESTful架構
CQRS架構
微服務架構
風險驅動模型
Clean Architecture思想
培訓計劃:
第一單元設計優良的架構
軟件架構是針對軟件系統、子系統以及模塊層次的設計過程，包括如何組織系統組件，管理組件之間關系以及指導設計的基本原則。
架構的定義
業界對架構的各種認識與定義。對組件的理解，對自治組件與服務的分析；組件與環境的關系。架構決策的關鍵性，架構設計的重要原則：關注點分離原則與高內聚、松耦合。
優良的架構
優良架構的特征：簡單、一致、清晰、自治。
設計簡單的架構：清晰地表達設計意圖，保證系統足夠小，促進恰如其分的架構設計。遵循?? “關注點分離”的架構原則，將架構的分離策略分為縱橫分離與內外分離。
設計一致的架構：設計風格的一致性，概念的一致性，解決方案的一致性以及路線圖的設計。
設計清晰的架構：隨著軟件系統變得越來越復雜，若能保證架構的清晰，將是避免混亂的關鍵。
設計自治的架構：最小完備特征、自我履行特征、穩定空間特征和獨立進化特征。
案例分析：當當?的架構優化，普華永道的架構演化
第二單元架構風格與參考架構
REST架構風格
REST描述了Web作為一個分布式超媒體的應用，相互鏈接的資源通過交換代表資源狀態的表述來進行通信。它是WEB系統架構運用最為文泛的架構風格。
案例分析：訂單管理系統的REST架構。通過案例講述如何在架構設計中運用REST架構。
基于消息的分布式架構
分布式架構是企業軟件系統主要采用的一種架構風格，通過使用基于消息的中間件完成消息的發送與接收，從而實現系統之間的集成，以及業務處理的異步模型。
案例分析：醫療衛生知識庫系統。通過引入消息隊列改善系統架構的質量。
數據為中的軟件架構
一般的數據管理系統都分為三個步驟： Data Ingestion、Data??Storage與Data Processing。在大數據處理中，這種模型體現得更為明顯。所有的軟件系統都離不開數據處理。此外，本節內容還會講解?? Spark所支持的MapReduce、Streaming等架構風格，剖析Spark的架構原理和最佳實踐。
案例分析：電信業數據分析平臺，分析基站、區以及客戶的通信行為、通信質量和投訴管理。
向服務的軟件架構與微服務架構
從SOA的服務設計原則到微服務（ Micro Service）架構，講解如何進行面向服務的架構設計。
案例分析：企業后臺支撐系統
第三單元架構模式與應用實踐
分層架構模式與實踐
講解經典的軟件分層架構以及當下架構設計對分層的認識與分解，并介紹了領域驅動設計中推崇的分層模
式。
六邊形架構模式與實踐
Cockburn提出的六邊形架構不僅是一種有效架構模式，同時還是一種非常重要的架構分析方法，重點關注模
塊（子系統）之間的通信與集成方式。
微內核架構模式與實踐
微內核模式是架構模式中極為重要的一種模式，尤其是它劃分功能子集為核心功能子集的設計思想非常重要，但它的重要性卻常常被人忽略。
管道-過濾器架構模式與實踐
若要實現數據處理的良好可擴展性，有效降低數據處理的算法復雜度，就需要運用管道-過濾器模式。
MVC架構模式及其延伸
MVC架構模式是最常用的架構模式，體現了關注點分離的架構原則。在介紹??MVC模式的同時，還將講解MVC模式的若干變化與延伸。
趨勢分析：前端架構的演化與發展
CQRS架構模式與實踐
CQRS模式即命令查詢職責分離模式，是 DDD中基于事件的讀寫分離架構模式。將業務邏輯建模為狀態機模型，并利用松散耦合的命令與事件機制，采用異步模型改善系統整體性能。
案例分析：會議注冊與管理系統的 CQRS架構
第四單元領域驅動設計
優秀的軟件系統與好的軟件設計息息相關，但最關鍵的還是在于對需求的理解。如果不能正確的理解軟件需求，那么再好的設計也不能設計出好的軟件。正確的做事情固然重要，更重要的是要做正確的事。領域驅動設計就是要解決技術人員對業務建模的問題，是分析獲得業務架構和應用架構的設計方法。
限界上下文（Bounded??Context）
若要進行領域建模，并將業務需求逐步演化為架構設計，則需要引入 DDD（領域驅動設計）的戰略設計作為指導。場景圖與限界上下文可以很好地結合，幫助架構師很好地識別各個子領域的概念邊界與設計邊界。如此則可以運用“分而治之”的思想識別出整個系統的業務邏輯邊界與物理邊界。
場景驅動
場景驅動設計的核心在于識別場景，它需要設計者結合具體的業務場景，分析業務流程，以此驅動出用例；再以用例驅動對業務邏輯的建模。場景驅動設計的核心模型為??6W模型，即Who，Why，When，What，Where與hoW。它將對應職責模型的業務價值、業務功能與業務實現，并從角色的角度思考對象之間的協作以及設計邊界。
用例方法 (Use Case)
通過利用傳統的用例方法來幫助我們驅動出領域的限界上下文。
演練：識別電子商務系統的限界上下文
上下文映射圖 (Context??Map)
本部分內容會講解限界上下文之間主要存在的組織模式與集成模式，這其中包括防腐層，開放服務調用等。利用上下文映射圖，有助于識別上下文之間的關系，思考處于上下文內領域模型之間的通信方式，從而幫助架構師驅動出最終的應用邏輯架構。
可視化演練：電子商務系統的應用邏輯架構
第五單元風險驅動設計與Clean Architecture
風險驅動設計
風險驅動模型主要關注軟件系統的質量屬性，通過識別風險來逐步驅動軟件架構設計，它強調進行恰如其分的架構設計。
風險驅動設計的過程風險驅動設計的過程分為三個步驟，即識別風險，并對風險排定優先級；選擇和運用適當的軟件技術來降低風險；評估風險是否得到降低。
案例分析：RackSpace架構的演進
風險評估模型
評估風險并非只是架構師的職責，而應該是整個團隊包括客戶共同參與的結果。本部分將引入可視化的Future Backwards方法，引導團隊搭建軟件系統的風險評估模型。
約束對架構的驅動
除了風險之外，我們也可以通過識別一些架構約束（約束的識別是通過與客戶的充分溝通，從質量屬性的角度來分析），并將其作為一種驅動力來逐步改進或者調整架構。技術債務也可以看做是另一種設計約束，我們需要隨時更新整個項目的技術債務，并制定相應的計劃去解決這些技術債務，從而進一步優化軟件系統的整體架構。
案例分析：約束對REST架構風格的設計驅動
Clean Architecture思想
Clean Architecture提出的模型是一個可測試的模型，無需依賴于任何基礎設施就可以對它進行測試，只需通過邊界對象發送和接收對應的數據結構即可。它們都遵循穩定依賴原則 ，不對變化或易于變化的事物形成依
賴。
演練：支付寶紅包發送系統的設計
第六單元架構關注點專題討論
專題一：高性能系統的設計
高性能是軟件系統設計無法繞過的話題，無論是企業架構還是互聯網架構，設計時都需要考慮如何滿足高性能的要求，尤其是在數據量越來越大，并發訪問越來越多的前提下，?性能會成為架構師必須要解決的問題。
本專題討論會給出高性能設計的常見問題、解決方案與最佳實踐。
案例: Twitter的高性能分布式日志，滿足了系統的可靠性、高吞吐量、低延遲、可擴展性等質量屬性。
專題?：分布式事務
當今的大型軟件系統都是分布式系統，隨著硬件成本的逐漸降低，網絡帶寬的逐步增加，我們已經告別單機時代。分布式系統可以更大限度地利用硬件的水平擴展，也能夠保證異構、異步系統的集成，但是帶來的問題也很顯著，除了運維方面的挑戰外，如何保證業務服務的事務，成了棘手的問題。
本專題會介紹分布式事務 ACID約束的問題，并講解 BASE原則以及CAD原理。
案例：通過對支付寶扣款到余額寶的案例分析分布式事務的解決方案。
專題三：大數據處理
大數據處理成為這幾年最熱門的話題，也是大多數軟件企業需要解決的問題：即如何在海量數據中尋找到業務價值。本專題會從技術角度剖析大數據技術生態圈，并主要介紹??Hadoop、Spark等大數據主流技術與平臺框架。
案例：Airbnb數據基礎設施的主要架構
專題四：函數式編程、事件與不變性
隨著多核硬件的普及，并行計算成為軟件開發的主流，這也為本來更偏向學院派的函數式編程思想變得越來越重要。函數式編程思想對軟件架構的影響則包括：數據結構的不變性、狀態遷移與事件處理機制。
案例分析：分析Redux框架以及Akka框架的設計思想，并講解??Redux框架在前端開發的運用， Akka框架在后端開發的應用。
第七單元大型軟件系統體系架構在線零售商集成解決方案
整個系統牽涉到電子商務、庫存管理、呼叫中心、郵件服務等多個系統的集成。該解決?案通過運用分布式系統的最佳實踐，運用基于消息的中間件，對系統進行整體設計，使得系統能夠高質量地支撐在線零售商的核心業務。
銀行保險客戶核心支撐系統真實案例，是某大型金融集團的客戶核心支撐系統，需要支持的業務系統多達數十個，且具有不同的業務，部署在不同的平臺。如何通過合理地設計，運用 ESB和REST對整個系統進行集成。
|
|
|
|
|
|
首頁 課程表 在線聊 報名 講師 品牌 QQ聊 活動 就業
