緣起

Use Case 的職責是把業務邏輯封裝，一個 Use Case 大致可以對應到一個 User Story。一開始我們對 Use Case 要怎麼設計並沒有太多想法，便開始整理以前的 User Story，發現大部分都可以歸納成

取得資料 → 業務邏輯 → 儲存資料

而單元測試內則是，"取得資料"對應到"建立測資"，業務邏輯則是測試的重點，"儲存資料"則應該被mock 或 stub 掉，因此第一版的 Use Case 設計的兩個對外的 method，一個是 create， 放業務邏輯，如果業務邏輯過長則可以用 private method 封裝，另一個則是 save ，放儲存資料的程式或 call 第三方服務，而在測試中只測 create。

這邊簡單用建立訂單舉一個例子

這時候 Boxenn DAL 的介面還沒設計出來

# Use Case 大概長這樣子
class CreateOrder
	def initialize(params:)	
		@params = params
	end

	def create
		# 其他邏輯 (如驗證、處理參數等等)		
		@order = Order.new(params)
	end

	def save
		@order.save!
	end
end

use_case = CreateOrder.new(params: params)
use_case.create
use_case.save

這樣做其實有不少缺點:

• 外部需要 call 兩個 method
• 處理資料與儲存資料不在一起，遇到需要同一個交易內的資料操作時，只能在use case外面包
• 沒有統一的回傳格式
• 例外處理需額外寫

這時候我們發現了 dry-monads ，他的核心理念是 functional programing 當中的 monad。

關於 monad 的解釋可以看以下資料

• 图解Monad
• Monad (functional programming)

那這樣做的好處是:

• 對外只有唯一的 method 可以 call
• 能處理錯誤 (可以在每一步定義)
• 容易閱讀
• 有了 Boxenn DAL 的輔助後，容易測試，也可以走 TDD

到此，我們的 Use Case 介面便有了雛形。
下一篇將會介紹 Boxenn::UseCase 的實作細節，以及如何使用。