[DAY18] Use Case 设计概念

缘起

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 的实作细节，以及如何使用。