---
# 架構師也要 DevOps - 談服務模型的持續交付 - Andrew Wu

{%hackmd @DevOpsDay/BJXaW1_k6 %}

## 講師提供的資訊連結:


* 簡報(演講開始後開放): [連結](https://docs.google.com/presentation/d/1-bZvI5B5gToB2BjvR3SUS2vM5KurnFH01tT9PESJOH0/edit?usp=sharing)
* 我的部落格: https://columns.chicken-house.net
* Facebook: https://www.facebook.com/andrew.blog.0928/
* [講者演講後的心得文章](https://www.facebook.com/andrew.blog.0928/posts/pfbid02kQXWAz1RyzgX8o2cWEdM1PAujF8rZVzJ8W1vsxXLD54BawQwKyJy33FxpR1iVo3bl)

----
> 共筆: 從這裡開始寫

前言

# 選擇這個題目投稿的動機...

- 體驗一下，實際上老闆想要的 "商業模型" 是什麼東西... ?
- 商業模型，決定了產品服務的樣貌
- 技術模型，決定了背後系統的樣貌
- 持續將商業模型，對應到技術模型，就是架構師的日常任務

## 讓團隊對其同樣的商業目的進而收斂建模, 再建立成技術模型

* 商業需求 > 商業模型 > 技術模型 > 收斂成簡單的模型
* API 是個商業模式

BizDevOps
* 業務需求，對應系統需求，再抽離出模型


Biz <-> Srv 是一個循環, 這裡要從商業模型抽象化出技術模型的重點
Srv <-> Dev <-> Ops是另一個循環

# 敏捷團隊中的架構師，該扮演什麼角色?

架構設計是一開始就要先看到全貌, 而不是蓋到哪裡才想到哪裡
進而持續循環細化設計
有些事情要事先規劃好

## Ref: [Role of Architect in Agile Development](https://www.agilearchitect.org/agile/role.htm)

# 範例 - 老闆想要 (聽) 的商業模型..

* 有門市銷售領域
* 疫情影響了實體門市的業績
* 開始發展出 app 與 錢包支付
* 有線上銷售領域
* 線上銷售與社群平台的整合
* 廣告模式、整合
* 多方整合後，其價值回饋到消費者上

- 建模的重要性
https://www.ithome.com.tw/voice/134113

# BizDevOps，由商業需求建立技術模型

* 系統與系統之間，會有資料的傳遞，相對就有 API 需求
* 把需求抽象化出模型
* 持續調整模型，趨近商業需求。
* 商業需求，要知道核心價值是什麼，能正確的進行模型設計。

# 讓模型能被驗證: 用 OOP 來建立技術模型

* 抽象化，描述主要商業目標，隱藏一切不相關的細節
* ( ex: 使用 Kubernetes 算不算 "不相關" 的細節? ) ( 架構師腦容量有限... )
* 降級的技巧
* 降級，是指講者對於“抽象化”的另一種說法
* 將模型對應到程式碼
* 簡化到 200 ~ 500 lines of code； 能驗證邏輯的情境, 用 unit test 對應

# 由模型來驗證監控指標

* 降級技巧的進階應用
* 已經可以讓你跑完商業流程跟設計邏輯的驗證，這驗證能否進一步拿來驗證維運?
* 拿同樣的技巧，應用在改善維運機制的設計
* 正確的設計模型，就能知道應該關注的指標為何。
* 模型除了拿來改善 Dev, 也該要能拿來改善 Ops
* Dev 端要從模型開始，推行 API First … , 而 Ops 端也應該要從模型開始，推行 Metric First …

Sim = Stimulation
## 零售業的全通路領域地圖
### O2O
### OMO
庫存整合更有效益

老闆講了14頁的商業模型和受眾以及商業競爭力, 甚至彼此之間怎麼整合來達成目的
但離寫成程式還很遠, 但架構師就是在分析跟抽象畫這些, OMO場景下能分成人, 場域, 貨品來劃分領域

# 建模的流程

- 設計
- 驗證
- 持續交付 : 這點是今天分享的重點

## 思考: 會員註冊的功能，你看到的核心價值是什麼?

抓到目的後, 將註冊重點的會員資料定義出狀態圖, 狀態的轉移會搭配對應的行為, 甚至也能找出調用行為的角色.
不讓第三方把資料拿走，但改版要外包

### 06-1. 對照組, 採用 CRUD 設計出來的 API Spec

行為不只有CRUD 四隻API
> 你要看透事物的本質，精準 (且毫不多餘) 的用模型來表達你的構思。

# 2. 讓模型能被驗證: 用 OOP 來建立技術模型

> Tech model -> POC的過程
架構師最重要的就是建模(modeling)和抽象化(abstraction)的能力,
交付時持續地確保交付的東西是正確的.
只要能設計成code, 就有辦法去驗證, 但設計時要降低認知負擔(找出邊界).

### 大型系統設計的複雜度:

> 最基本的模型，就是 Entity + Operation + State Machine ( Life Cycle )
更細緻的模型分析，首推 DDD ( Domain Driven Development ) 的方法論

工程師往往做了很多最佳化, 但未必有對其商業需求,雖然符合規格也通過了測試.
換句話說就是缺乏因應商業走勢來變化的彈性 => 會形成技術債

> 抽象化後降級設計, 將各種架構選擇的重要元素，都先抽象化成基本程式語言就能表達的層次，並且先在腦袋建立好 "對照關係"
因為降級了設計, 不用真的準備好所有的環境, 能寫個簡單的POC串接流程做驗證.

#### Message Queue引用的思考

也許要的不是message queue,而是messaging的管理

# 3. 由模型來模擬驗證監控指標

> Tech model -> Sim維運

## 開始之前，試著自己回答這幾個問題:

- 呈現一堆主機與性能監控

## 我心裡理想的業務監控，應該是這樣:

> 系統指標 + 監控系統 => 成熟可靠的監控方案
商業指標 => 大部分都是跑報表，或是 RD 自行開發的監控 "功能"

透過降級設計, 快速將資料呈現成指標後, 確定這些指標是不是自己未來在營運環境上想看到的圖表, 甚至能跟運維團隊講解這些與業務行為的掛鉤.

指標在系統已經上線後, 要再測量採集會有難度.
但能透過建模, 抽象化, 降級, 早期就能察覺到這指標的需要性.

Metric First: 盡早確認監控，維運才能順利

建模日常, 在找出模型的認知/職責邊界進行模型切割

每個區塊都是一個模型, 都有附上文章連結

模型的最大價值：
* 能夠明確抽離出需求、分界

### 可探討的問題？

降級之後，是否能夠再升級呢？

----

### Q & A, 歡迎留下問題, 演講結束後可以找我聊聊.

留在這邊的問題, 我這一週內都還會過來回覆, 單純的意見回饋也歡迎~

> [name=Andrew Wu][time=Oct 4,2023 17:50]
> 活動過去一個多禮拜了，問題我就回覆到這邊了喔 (這段期間我每天都還有來詢一次)。之後還有問題的話歡迎到我的 facebook 粉絲專頁留話跟我聯絡 :
> * 我的部落格: https://columns.chicken-house.net
> * Facebook: https://www.facebook.com/andrew.blog.0928/

> [name=Alvin]
Q: 想詢問 Andrew，身為工作經驗約 3 年的菜鳥後端工程師，要怎麼在日常開發過程中，訓練今天提到的一些架構師的能力與觀點？例如建模、降級。或是對於這種初階工程師，想要往架構師邁進的話，有什麼從現在開始、可以在日常中應用的技巧或是思考方式？感謝

> [name=路人]請供小建議
> 1. 先從本身負責的服務去思考其他相依服務、上下游，如何讓他們使用你的功能時，具備清楚與易使用，站在服務與服務的邊界去改善兩者的互動
> 2. 建模、降級的部份先從原本的服務完全去除有關data persistence(如資料庫)的影響，使用簡化的類別模擬相關作業後仍然可以運作並與互動，再逐一剔除與本核心業務非直接相關的服務

> [name=William Yeh]
> 也可以試著強迫自己，只用 clean architecture 最內的兩圈來設計（entities + use cases），這樣就容易達到初步的建模 + 降級。

> [name=Andrew Wu][time=Tue, Sep 26, 2023 13:30 PM]
> 架構師要面臨的挑戰是 "廣度" + "深度" 都要兼具，說實在不是件能速成的事情。昨日的分享我有提到多次，基礎是重要的，而且要熟練，否則你的認知負擔會處理不了 (抽象化不夠，你就有太多細節要溝通)。抽象化跟降級是你不得不做的動作。
>
> 我的建議跟 William Yeh 一樣，先從小規模你已經熟悉的案子 (甚至是半成品都可以) 回過頭來重建模型，並且驗證看看。簡單的模型其實狀態機就能搞定了，DDD 也不用太早接觸，沒有足夠基礎就去碰這種流程框架，其實你會掌握不到重點的。掌握好 State Machine, 確保你的 Entity / Database Schema 到位, 你的 API / Service / Command 等等也都到位，再開始思考更大範圍的問題。
>
> 最後，別把架構師當作你必要的發展方向，不是每個工程師最終都要變成架構師的。高度抽象化的副作用，是你無法顧及太多細節。你會少掉很多親手把東西蓋起來的樂趣，所以我會建議你至少每個領域 (語言、前後端、資料庫等等) 都至少有一個專精的程度時，再考慮往架構師發展。你在特定領域已經夠深，你才有本錢發展廣度 (而且人家要能服你才算數)。

> [name=Alvin (原 PO)]
> 感謝各位大大的回答與建議～

thanks

----

## 共筆聊天室：

- 講者有事先提供簡報，很讚！推推推推推！

講者語速適中又平穩，nice

商業建模是否就要談到 DDD，再來 OOA/D？
果然提到 DDD 啦！

蔡學鏞大現在好像都是在企業當顧問？蠻久買看到新文章了

~~痣~~


還好樓上不是貼聖物的照片