本文
這次主題主要是分享主題是架構師是如何從商業應用場景來設計目前的系統架構。
1、架構思維
傳統我們對架構師的期待可能就是技術要很強、懂得如何建構系統就好(還是其他人的印象不一樣，只是我以為？)
講師 Jed 分享下對這印象改觀了不少。
架構師的腳色定位為何?
- 技術的廣度與深度
- 處理人與人之間的關係(軟實力)
- 理解與實踐組織期望
傳統的場景比較像是由架構師一人規劃系統、負責核心底層，後續才交由其他PG設計。
但 Jed 這邊分享認為更好的方式是兩邊一起緊密合作溝通而非單向傳授，畢竟架構設計並沒有完美這件事…
這邊也提到架構師很難專精某一項技術，因為有許多考量、商業考量、安全性考量、預算考量，要學習的範圍擴大，不只有技術這一項需要學習而已。
最印象深刻的是 Jed 分享提到以技術深度來說，團隊內的工程師經理、資深工程師都有比自己更強的部分，但架構師要懂得更廣。
中間也帶了一個小範例講解兩種快取可能需要考慮到的地方。
最後帶到了
架構師的第一法則
軟體架構的一切皆是取捨，技術了解的深度與廣度，要考慮業務面的需求。
小節：
過去:
架構師設計核心底層、元件開發。
可能造成的問題
當架構出了問題，架構師必須要在才能改的動
造成了架構上的瓶頸
這邊自己心得分享，目前工作確實也遇過幾次因為先前設計架構的架構師不在了，大家想要改動卻礙於對架構不夠熟悉、不夠了解，不敢輕易去改動。
所以新的方式:
應該是讓架構師規劃後，讓團隊成員去開發。
架構師應該只需要負責一部分的業務需求開發，這樣除了維持架構師的技術，也能提升團隊成員對整體架構了解程度。
2、需求結構化與架構特性
來源書:一線架構師實際指南
- 功能性需求(Functional Requirements)
- 約束性需求(Constraint) Ex:資源約束、商業約束、法律約束、資安約束等。
- 品質屬性(非功能性需求 Non-Functional Requirements)
品質屬性，最常被忽略，需求單位不會知道這是甚麼，大多是需要技術人員才能提出
ex:效能相關問題，頁面的回應時間要低於幾秒，同上人數要多少?
這邊也帶了一個小範例電商需要考慮的需求矩陣有哪些
重點：不同的需求其實會有交互影響的。
所以應該要考量：
不同的需求依照不同的層級歸納出我們需要注意的東西是甚麼
可以依此找出關鍵需求，哪些是不能放棄的，再來決定要用哪個架構特性。
關鍵要做到：
3、軟體是為了解決複雜問題
這個小節最大重點應該是右下那張圖XD
盲點： 不要從技術的角度來設計架構，會與現實脫節，因為商業才是現實面最大的考量。
從第一場 Gipi 院長到第二場講師 Jed 分享都有一再提到過這件事，技術開發者很容易陷入由技術為主要考量的出發點，但現時面還是要回歸到商業，畢竟一間公司的營運都是需要考量到錢。
在此就有提到幫助釐清問題的邊界方法，有帶到了 DDD。
主要有三個邊界需要考量：
- 商業問題邊界
- 人員溝通問題邊界
- 技術邊界
Jed 提到當你理解商業時，可以幫你驅動技術變化，而當你的技術進步，有時也會促進商業進化。
商業的策略驅動軟體服務的進化實例：
很多公司把軟體變成 SaaS 服務。
舉例: Adobe photoshop。
事後來看 SaaS 服務已經遠高於單機版的軟體。
這邊一樣帶了一個小範例，接著就是思考如何進行分析需求：
第一步制定目標:
客戶方:讓客戶更方便下單。
營運方:更容易確認客戶問題，訂單問題。
impact mapping
第二步 user story mapping:
用這個地圖能夠聚焦業務面與技術面共識。
第三步釐清具體需求共識
Ubiquitous Language: 不只是專有名詞文件化，而是要集合所有人的共識，並落實到程式碼、測試、文件、溝通之中。
這些文件最大重點是要能夠持續整合、重構與進化。
建立完文件後開發團隊與測試團隊就能了解各自需要做甚麼。
提醒:要讓整個專案團隊對需求要有共同認知。
範例：
接下來就是找出重要的概念
建立模型：
4、定義問題與解決方案
首先問題的拆解
歸納有兩種問題:付款問題、訂單問題。
第一個問題會是付款問題，需要考量的是使用的第三方支付可能會遇到很多無法掌握的狀況 Ex:網路問題、安全性問題、無腦回200 OK 但是沒成功問題(?
設計架構時，就可以把外部金流的風險獨立出來成一個解決方案。
這樣的好處是第三方支付有可能不只串接一家，可能是好幾家，所以應該要讓所有金流解決方案能夠共用一個解決方案。
5、持續改善架構設計
初始架構圖
思考:
高內聚低耦合如何達到。
透過 DDD 方式定義完業務範圍能有效達到此目的。
推薦書 : 演進式架構概念。
同步共生性:
兩個服務的架構特性不能有太大的差異
ex: 如果訂單服物要擴展訂單量，金流服務就要同步擴展，不能會撐不住，可是又要同時考慮我們是使用第三方服務。
非同步共生性:
非同步方式能夠解決兩邊耦合程度。
ex:上述說的狀況單訂單服務擴展訂單量，就算量在大也需要透過 message queue 來與金流服務溝通，訂單方可以馬上回復使用者訂單處理中，金流服務擴展也較有彈性。
架構演進-資料庫切分
ex: 現今微服務的架構大多如此
但現在的問題同步通訊還沒解決。
需要再度演化架構
Mediator pattern
但缺點是架構變得更複雜。EX:當一個地方出錯，會需要更多機制去 debug，難度會比上一個架構難上更多。
不同的架構風格有不同優點與風險，架構師此時就是要讓團隊理解這項決定帶來的改變。
(重點是根據架構的改變，缺點可能不會永遠是缺點)
6、其他同樣重要的部分
這邊都是需要費心去處理的事情。
尤其是投資基礎工程實務不可以省，開發主管不管如何都應該撥出時間去處理。
團隊協作流程圖
7、QA
這邊就紀錄自己比較有印象的幾個問題。
非功能性需求如安全性、可用性的部分，在作架構規劃時可以怎麼去判讀優先順序？
Ans : 回到需求結構化那段，拉出架構特性跟品質需求內容，跟團隊、需求方經過激烈的爭辯討論出需要取捨的部分，架構師再來建議那些方案比較好，並不是架構師私自決定。
(所以這個部分是大家激盪出來的)
ex: 面臨哪些風險，那採取這個方案後，應對方案是甚麼，接下來如果我們開發遇到這些問題，該由誰來處理這些問題。
請問一下 Jed 覺得如何技術廣度如何培養 有什麼建議的方向嗎 ?
Ans : 多參加活動、多與其他開發者交流，不要預設立場的與別人交流，去了解其他人認知是如何。
關注世界上流行的技術是哪些、要注意技術的適用性是否符合現在團隊，與大師們交流。
請問好的架構師如何養成呢？感覺需要掌握新資訊，需要了解人事時地物全貌，亦需理解人性，知道如何溝通。請問是否有相關經驗可供傳承？又哪類領域的 IT 或特質的人或職位的人，適合邁向架構師呢？
Ans : 站在技術以外的架構思考、讓自己開放一點，不要把技術當成解決方案的必要手段，技術只是工具。
在規劃架構/導入技術的時候,如何說服老闆給時間跟金錢,例如老闆可能無法理解基礎工程的重要性,這類問題該如何去解決?
Ans : 以錢的角度出發來分析。(就是用錢啦用錢!!!)
雖然前面有回答任何人都可以當架構師，但又有提到當架構師是一個賭注，那麼有什麼東西是對於想當架構師之前應該要想清楚的? 以及能否分享當架構師最棒最有成就的事？
Ans :
要想清楚的
- 1、可能沒有時間去寫 code。
- 2、原本很厲害的技能就不那麼厲害了。
- 3、理解商業，理解組織，要了解談判，籌碼交易等。
- 4、多出溝通協調，參與政治議題。
- 5、從對方的說法了解內在議題。
最有成就的事情
- 1、團隊協作真的解決了他們的問題，而非架構師自己解決。
- 2、讓業績真的有所成長。
最後還是強調每個人要的不同。
8、提到的書籍
後記
最大收獲大概是對架構師這個職務改觀，多了滿多自己職涯規劃的想法，總之要學的還多前方路還長。