# 領域驅動設計應用與實踐 / 張國昭 (小張)

{%hackmd @ModernWeb/SyA2U6SmT %}

> 共筆請從這開始
>
領域驅動設計（Domain-Driven Design，簡稱DDD）
key: Design

## 設計概念

### 好的程式碼

#### 易於閱讀：因為8成的時間都在閱讀程式碼，而不是在寫程式碼，寫得容易被看懂就變得很重要。

- 抽象一致：有些code有的被抽象化、有的沒有被抽象化，應該要統一才對。
- 揭露意圖：有時候看不懂你的程式碼在寫什麼(要做什麼).
- 統一語言(Ubiquitous)：溝通最大的問題是不知道對方在說什麼。很常在最後的時候問你有沒有問題，但可能沒人會回答？因為大家也還沒釐清自己有沒有問題，甚至自己有問題也不說。

:::info
一段程式碼被閱讀次數遠大於他被修改的次數
:::

#### 掌控修改：真的發現是我的問題的話，可以很快被修改好嗎？
SOLID

- 單一職責
- 開放修改
- 里氏替換
- 依賴反轉
- 介面隔離

:::info
要想程式碼可以被修改, 首先要讓它是好被修改.
:::

#### 難被影響

- 有效耦合：系統很難被完全獨立，勢必會發生耦合。要怎麼樣才能讓耦合是有效的？程式碼內部是不是有無效的耦合？(平常就開個design meeting 大家一塊來review)

- 避免概念汙染：程式碼之間一定會互相溝通，每個屬性都要有他的意義，彼此之間的意義是否有 match 很重要
（什麼是好的API:避免對方屬性跟自己不一樣要有適當轉換）
- 充分隔離：

我要修改這個功能，你什麼時候可以修改好？可以先估個時間給我嗎？
:::info
分析變化的頻率範圍，???
:::

### 設計

- 對外揭露意圖：可以很輕易讓外人知道我這段程式碼的意圖
- 對內解決問題

錯誤示範：註解很多行，原因只是或許之後會用到

#### 設計的運作模型——雙菱形模型
(credit [nngroup](https://www.nngroup.com/articles/discovery-phase/))

**問題**的探索與歸納：經歷問題的探索和歸納之後將成功視為一個集合
- Discover：在探索的時候盡可能的收集資訊，不要覺得可能用不到就不搜集。（盡量發散 Diverge）
- Define：依據現有資源聚焦 Converge

**解方**的發想與精練：對應問題的集合、解決方案也需要有對應的解決方案集合
- Develop：各種解決方案
- Deliver：交付出去的答案/成品

:::spoiler 甚麼是完美？
我沒辦法再刪除它了
:::

#### 設計的歸類
- 問題的探索+歸納
- 經歷問題的探索和歸納，之後將成功視為一個集合
- 解方的發想與精練
- 對應問題的集合,解決方案也需要有對應的解決方案集合.

從問題空間 mapping 到解決方案空間
2個空間的橋樑就是DDD

解決方案的空間

### 設計的細節

領域驅動設計專注在讓開發的流逝循環的。蓻做的結果會反映前期的作業是否需要調整與修正。再將確認後的結果，體現在當前的實作上。

問題空間 <---- 領域驅動設計 --->解決方案空間

搜集分析 --- 交付 ---> 設計 --- 交付 ---> 實作
　　　<---- 回饋 -----┘ <---- 回饋 -----┘

#### 設計細化的目的
左半邊：了解領域知識，拆分之後，分析轉化成**開發藍圖**
右半邊：精煉領域模型，輔以設計，配合**模式**成：**可均速持續交付軟體**

## 啟動

### 產品開發

產品開發是任何產品驅動型公司的主要驅動力。從構思、設計到最終執行。
一款出色的新產品可協助公司在競爭中領先一步，佔領新市場並增加利潤。

創意起點 -> 掙扎、探索 -> 團隊對齊

### 分析與蒐集資訊

> 在進行產品開發之前，需要對於現況進行分析，以避免摸著石頭過河的窘境。

競品分析 -> 利害關係人分析 -> 顧客旅程地圖(可分析競品)

## 找產品的起始點 - 價值主張

價值主張是指組織或實體在其客戶群中推銷自己並建立品牌，而做出的令人信服的聲明。他是商業實體普遍採用的一種行銷策略，旨在為用戶、訂閱者和潛在客戶增加價值。

你判斷不可行的需求，背後你一定有一個價值的判斷標準。

- 行銷策略
- 交付價值
- 品牌推廣

### 探索核心
(credit [b2binternational](https://www.b2binternational.com/research/methods/faq/what-is-the-value-proposition-canvas/))
價值主張畫布與顧客輪廓彼此之間相契合。在列出收益創造者(Gain creators)、止痛藥(Pain relivevers)以及產品/服務後，確定的每個點都可以依據對客戶的價值從：**最好有**到**必須**進行排序。

哪些該先做、哪些晚點做。可以透過二維矩陣分析

[二元矩陣圖](https://miro.medium.com/v2/resize:fit:1032/format:webp/1*QPCvWA6MYekrb7DScJIBfw.png)
Core messages (核心關鍵)
Areas of improvement (核心問題)
這兩個在二元矩陣圖都很重要
一個解決痛苦，一個製造快樂

### 第一階段的重要產出

從上述的步驟中，最終整理出兩個重要的產出：產品願景宣告書、產品說明書。
在這兩項產出在後續領域驅動設計中，扮演重要的角色：

- 產品願景宣告書：價值主張
- 產品說明書：詳細描述到底願景宣告書在做什麼

一圖勝過千言萬語，但你的一圖沒人懂，所以又要用千言萬語在講述你的一圖。

### 挖掘使用者真實需求
以真實需求為**核心**，其根基為**場景**。按照真實需求進行提案以及深度探索；研究成果可以作為設計的假設，進而確保設計的完備度。

### 開發的起手式
.
　　　　　　市場
　　　　　　ˇ
使用者 -> 產品 -> 開發
　　　　　＾
　　　　　企業

設定第一個版本的**開發流程**，並且設定回饋機制，讓開發流程能不斷改善。
除了流程之外，制定開發規範讓大家有遵循的規則，也能加速開發效率。
為了讓產品背後的領域知識能夠讓團隊所有成員快速理解，領域塑模是必要的。

- 制定開發流程：例如：要不要做PR?CICD?
- 社交合約：大家會開發、但大家處的沒有很好（沒紀律，開會愛來不來之類的），所以社交合約就很重要。
- 領域塑模：
- 流程塑模
- domain model 塑模

#### 領域塑模

運用**事件風暴**工作坊(Event storming)讓產品背後的領域知識在團隊內部共用釐清與學習。在獲取領域知識後，將學習的成果萃取出物件，並繪製成圖，而這張圖能夠充分表達領域中的關鍵物件，其彼此之間的關係。

塑模只需要 Miro 或便利貼就可以開始做了，塑模就是在建立認知

領域物件塑模：想像這個世界只有自己

## 將龐大的知識切割

進行事件風暴的過程中，團隊會逐漸**對齊（Alignment）**領域知識

拆解成子領域有助消化知識
### 子領域的分級
核心：可以贏過別人的部分，最需要花資源的地方
支撐：可僱用他人來取得支撐
通用

### 限界上下文-領域故事彙整

### 資源調配
### 戰略地圖
### 拉齊領域知識與程式碼
code as document 程式碼跟文件差不多了，看文件就知道程式碼長怎樣，看程式碼就知道文件長怎樣。

## 領域驅動設計軟體開發

### 領域模型的細化
創新的關鍵：Job Story - 描述場景

### 程式碼即文件
程式碼跟團隊知識一樣
### 領域驅動設計的開發小工具
戰略就是資源分配
把開發人員放在核心功能，把資源做最大化利用

- 聚合：把相同的模型合在一起

### 不可避免的議題 - 模組化

模組化公式
先求內聚，再求耦合

### 架構也是
架構也要先設計好，不然長久下來即使有 DDD 也會難以維護，造成商業價值下降

### 垂直式拆解：需求與開發模式
讓程式碼變得更加精鍊

## 開發日常

### 持續整合

花時間整頓系統和開發人員、確保大家都是一致的

---
以下聊天室

DDD Taiwan / ACT

好奇台灣有多少公司真正做敏捷
> 你的敏捷不是我的敏捷
> 台灣很多公司都在跑 scrum like
> 只是變成每天review進度的瀑布實踐

很大的問題是工程師通常是在接到spec之後才進行開發

>> 很多工程師至在意技術不在意為什麼

投影片會後會提供

>> 讚讚讚
>> 可以問一下投影片在哪邊嗎QQ

TODO 就是不會DO (點讚)
該 Do 現在就 Do

如何驗證真實需求？
> 看你有沒有做對 （Ｘ
> 看客戶是否買單 (?)
> 看客戶有沒有 哎

>> 這是嘆氣的意思嗎ＸＤＤ

把三天的 DDD 壓成 40 分鐘就是簡報快講不完
想聽完+1
40分鐘太勉強

時間太短QQ
想聽完+1

>官網有放投影片連結，但link是null可以重放嗎？