我發現 直接看 domain model 的測試 好不好讀 就可以了
domain model -> 我直接看測試易讀性 有空才看 model 本身
application -> 操作真實流程，檢查 DB 與副作用
甚至可以說，model 本身是實作細節，測試才是真正要維護的介面
這樣 省時間 又優雅 又穩定
AI Coding 時代，我不再逐行讀程式碼
我現在更傾向用兩種方式驗收系統
Domain：直接讀測試
對 domain model，我甚至不一定先看實作。
我先看測試好不好讀。
Domain model 的可讀性，可以先從測試的可讀性判斷。
如果一個 domain 很難寫出簡潔的測試，通常也代表它的責任、狀態或邊界還不夠清楚。
Application：直接操作，再看資料庫
Application layer 的工作，大多是把流程接起來：
HTTP Request
→ Domain Input
→ Functional Core
→ Transaction
→ Database
→ Response這一層與其逐行閱讀 controller、service 和 repository，我更願意直接操作 browser。
我會真的走一次使用者流程，然後檢查資料庫最後存了什麼。
這種方式驗證的不是「程式碼看起來合理」，而是「整個系統真的產生正確結果」。
人不再審查每一行，而是審查可觀察行為
這套方法的核心不是不看程式碼，而是不再把逐行閱讀當成主要的正確性證明。
我真正關心的是：
Domain
→ 測試能否像規格一樣閱讀
Application
→ 真實操作後，資料與副作用是否正確至於 controller、view、JavaScript，只要它們沒有承載商業規則，大多可以交給 AI 生成，再透過整體行為驗收。
maybe 權限、金流 callback、transaction、冪等性、庫存競態與安全邊界，仍然需要少量高價值的 feature tests 保護。
共有 0 則留言
文字內容提供幾種功能：
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
⭐️ Shopify 網站開發服務（給品牌）
https://job.turn.tw/shopify-services
⭐️ 小網站開發服務（功能明確、規模不大的需求）
https://job.turn.tw/small-website-services
⭐️ 台灣 Shopify 商家交流 LINE 群（非官方）
https://line.me/ti/g2/PZ_1LILWVWWuzZQ50HNpYA-A3k6QXWF6znqoBQ
⭐️ 台灣 Shopify 開發者 LINE 群（非官方）
https://line.me/ti/g2/YUasX5K3CJ4QdIx76zppjHlh3-q8w-xkSyK1LA
https://job.turn.tw/shopify-services
⭐️ 小網站開發服務（功能明確、規模不大的需求）
https://job.turn.tw/small-website-services
⭐️ 台灣 Shopify 商家交流 LINE 群（非官方）
https://line.me/ti/g2/PZ_1LILWVWWuzZQ50HNpYA-A3k6QXWF6znqoBQ
⭐️ 台灣 Shopify 開發者 LINE 群（非官方）
https://line.me/ti/g2/YUasX5K3CJ4QdIx76zppjHlh3-q8w-xkSyK1LA
熱門文章
