---
title: "使用案例與服務 - Rails 開發實踐"
date: 2023-10-27T00:00:00+08:00
publishDate: 2023-10-27T00:00:00+08:00
lastmod: 2023-09-03T17:33:12+08:00
tags: ["經驗","心得","Rails","Rails 開發實踐"]
series: "rails-in-practice"
toc: true
permalink: "https://blog.aotoki.me/posts/2023/10/27/rails-in-practice-usecase-and-service/"
language: "zh-tw"
---


Entity（實體） 和 Aggregate（聚合） 是商業邏輯的基礎要素，我們將資料轉換成有意義的資訊，若要討論到該如何運用這些資料，那麼就屬於 Service（服務）和 Use Case（使用案例）的負責的部分。

<!--more-->

## 服務{#service}

如果已經對 Ruby on Rails 有一定的熟悉程度，那麼應該會聽過 Service Object（服務物件）的概念，實際上這種物件所指的就是 Service 所負責的任務。

在過去的 Ruby on Rails 中曾經有過 Fat Model 的概念，就是盡可能把所有邏輯集中在 Model 中。然而在複雜的系統下，會讓 Model 變得難以維護，若是我們繼續細分，在 Model 層級下大致上能區分出以下幾種：

* Value Object（值物件）
* Entity（實體）
* Aggregate（聚合）
* Service（服務）

這幾類物件基本上就是構成商業邏輯的部份，也是為什麼在 Rails 的文章中通常會說「把商業邏輯放到 Model 中」的原因。

Entity 和 Aggregate 負責維護狀態的改變，那麼 Service 負責的就是協調不同物件和背後邏輯的任務，在訂閱機制中我們就用來進行「確認訂閱狀態」以及「更新訂閱狀態」的處理。

## 使用案例{#usecase}

在大多數時候 Entity、Service 都是一些零散的物件，要將這些物件組織起來構成一個完整的流程就是 Use Case（使用案例）所負責的任務，以「建立訂閱」作為例子，我們要完成訂閱相關的事務處理，需要完成以下任務。

* 檢查訂閱狀態
* 建立新的訂閱
* 保存訂閱狀態

在 Model 層級下的概念，會由 Service 來處理其中某幾項任務，因此在比較複雜的使用案例中可能會有許多 Entity、Aggregate、Service 在這之中互相協作來達成任務，甚至會有需要跨越邊界的狀況發生，因此我們會在 Use Case 的層級下協調這些物件完成任務。

除此之外，我們應該將系統視為「不存在隨機」的方式下去設計，在這樣的狀況下像是「現在時間」這類資訊，就會在 Use Case 中被確定，後續的商業邏輯（Model 層級）都會以參數的方式接受這些資訊，來避免「無法確定」的結果出現。