我們試圖把命令與查詢從介面上分開，分開的原因是因為當狀態改變，其實會受到影響的狀態不只一個，會受到影響的查詢指令也不只一個。如果命令與查詢能在介面上分開，那這兩種行為便不會直接影響彼此，而是命令改變狀態，狀態改變查詢的回傳值，就能更鬆動地組裝功能了。
然而，也不一定所有命令與查詢都得分開，在網路 I/O 參與其中時，網路 I/O 的時間與資源也得考慮。例如，Client 下了一個命令後總是想看新狀態，這時，我們如果堅持不直接回傳新狀態，那 Client 還得再打一次 API，這樣也不見得划算。
此時，最外層介面我們可以二合一無妨，但裡面的實作我們依然可以先下命令，再下查詢。如此一來，就效能設計兩不誤了。
我們最後發現這裡有個業務概念：Reel 浮現了，但我們不確定現在抽好不好，於是我們就「試寫」一下，確定抽了以後，程式真的有變乾淨，這時 git reset，再用 TDD 的方式正式的寫一遍。
iThome鐵人賽
看影片追技術