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