LoginSignup
33
26

まずはじめに

この記事では、私が、ユースケース(Usecase)を
「使った方が良さそう」や「使わなくても良さそう」
を判断するときのポイントを書かせていただこうと思います。

当たり前だろ!と思うことかもしれませんが、
現場で「どういう時に使い分けてますか?」と聞かれることが多々あるので、
今回その内容をアウトプットできたらなと思います。

(ユースケースを "使う" という表現が正しいかは怪しいですが、文脈で汲み取っていただけると嬉しいです)

Usecaseとは

まず、ユースケースの基本的な定義から説明します。
chat-GPT先生に聞いてみた結果がこちら

ユースケースは、ビジネス要件やシステムの機能を実現するためのシナリオや振る舞いを表現する概念であり、
システムのユーザー(エンドユーザーや他のシステム)が実現したい目標や操作を捉えます。
ただし、ユースケースを必ずしも作成する必要はありませんし、
プロジェクトの規模や複雑さ、開発チームの特性などによって、ユースケースの使用や定義の程度は異なる場合があります。

これをみていただいてわかるように、ユースケースはそもそも使わなくても
「なんとかなりそう!」
っていう場面があります。

ただ、使っておくと後々改修時に
「このユースケース呼び出せば改修終わりじゃん!ラッキー」
となる場合もあります。

そこで、いよいよ本題です。
そんな「ラッキー」となる場面を増やすためのユースケースの
使った方が良さそうなケースをいくつか挙げさせていただきます。

ケース1: ユーザーごとに処理を分岐させる場合

ユーザーの特定の属性やステータスに基づいて、処理を個別に分岐させる場合は迷わずユースケースを使うことが多いです。
例えば、下記のような場合です。
 「ユーザー階級ごとに購入時のポイント還元率を変える」
 「ユーザーの登録経路によって送信するメール内容を変更する」

実際のソースコードだとこんな感じで書いてます。

<?php declare(strict_types=1);

namespace App\UseCases\User;

use App\Enums\UserType;

class PointUseCase
{
    /**
     * [UseCase] 会員ごとの還元ポイントを計算
     *
     * @param  User  $user
     * @return int
     */
    public function run(User $user): int
    {
        switch ($user->type) {
            case UserType::NOMAL:
                return $this->normal($user);
            case UserType::PREMIUM:
                return $this->premium($user);
        }

        return 0;
    }


    /**
     * 通常会員
     *
     * @param  User  $user
     * @return int
     */
    private function normal(User $user): int
    {
        $point = 0;
        // ここで色々Serviceから取得したり、計算したりする
        return $point;
    }


    /**
     * プレミアム会員
     *
     * @param  User  $user
     * @return int
     */
    private function premium(User $user): int
    {
        $point = 0;
        // ここで色々Serviceから取得したり、計算したりする
        return $point;
    }

(現状、私がジョインしている案件ではそれぞれのユーザータイプごとにする処理がそこまで大きくないので一つのユースケースの中で分岐するような感じで書いてますが、今後ユースケース膨らみそうであればユーザータイプごとにさらにユースケース使うのもありだなーとは思ってます...)

ケース2: 複数の処理をまとめて実行する場合

ある処理の中で、複数のステップや操作を連続して行う必要がある場合があります。
こういう時も複数の処理内容を一つのブロックとしてまとめるという意味合いでユースケースを使ったりすることが多いです。
例えば、下記のような場合です。
 「ユーザーテーブルにレコードを追加し、追加したユーザーのメールアドレス宛にメールを送信する」
 「ユーザーの商品購入テーブルにレコードを追加し、商品在庫テーブルのレコードを更新する」

ケース3: 将来的な再利用性を考慮する場合

ケース1やケース2に当てはまらない内容でも、
「将来的に分岐していきそう。」
「将来的に他の機能でも同じことしていきそうだな。」
と感じたらユースケースを使うようにしています。

最後に

色々書きましたが、冒頭でも記述した通り、ユースケース自体は必ずしも使わなきゃいけないものではありません。
ただ、使っておくと将来的に自分やメンバーを助けることになるものでもあるかなと思っています。

みんながハッピーになるコードを私はこれからも書き続けたいし、
そういうコードがどんどん増えてほしいなとも思っています。

まだまだ、試行錯誤中ではありますが、
少しでも誰かの役に立てれば嬉しいです。

(そして、「もっとこうするといいよ!」ってことあればコメントでそっと教えてくれると嬉しいです。)

33
26
3

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
33
26