何故学び直すのか
学生時代に大まかなService・Repositoryの役割について学んできました。
ですが、学んできた役割と実際に業務で使用されているService・Repositoryの役割の違いについて学ぶことが出来ました。
業務内にて学んだことをまとめながら記事を書ければと思っています
3階層システム
今回の記事に対して前提として「3階層システム」という概念を理解していくことにします。
システムの構成方法の一つになります。分けられ方としては下記のようになります。
- プレゼンテーション層(ユーザーインターフェイス層)
- UI・UXなどのユーザーが見る部分
- アプリケーション層(ビジネスロジック層)
- システムの処理がある部分
- データアクセス層(データベース層)
- データに読み書きする部分
今回はアプリケーション層(ビジネスロジック層) = Serviceとデータアクセス層(データベース層) = Repositoryがメインの話になってきます。
Serviceの役割
Serviceはビジネスロジックを担当していきます。
ビジネスロジックは「アプリケーションビジネスルール」と「エンタープライズビジネスルール」の2つに分けることが出来ます。
- エンタープライズビジネスルール
- システムに関係ない業務内のビジネスルールのこと
- アプリケーションビジネスルール
- システムがあってこそ成り立つビジネスルールのこと
- 例：DBに保存できるように
Repositoryの役割
データベースとのやり取り、外部APIとのやり取りを担当します。
業務を経て学んだこと
上記に記載したServiceの役割・Repositoryの役割については学生時代んに学んだことと業務上では違いがありませんでした。
ですが、大きく違い・学んだことは「Serviceに役割を持たせ過ぎてはならない」ということです。
今まではRepositoryはデータベースからデータの取得、Serviceでは取得してきたデータを整形をしてControllerに渡すと考えてきましたが、商品ごとの売上・作品ごとの売上などのような情報を出力する際に売上の計算を全てServiceで行ってしまうとメモリを食い尽くして正常に機能が完了しないという事案が発生することがありました。
そのため機能を正常に完了させるにはServiceに処理を集約させるのではなく、Repositoryで出来ることを(売上の計算など)を行うことでメモリを食い尽くすことなく正常に処理を完了することが出来ると学びました。
また、Repositoryではデータベースからデータの取得・売上の計算を担当・ServiceではRepositoryから受け取ったデータを整形するという役割分担をすることでよりコードが読み安くなることを学びました。
最後に
学生時代に学んだことは業務で活かせる場面が多くありました。
ですが、業務で使用方法は実際に業務に携わることでしか学ぶことが出来ないものだと学ぶことができました。
今後も今まで学んできたことを業務ベースに書き換えて今後のエンジニア業務に活かしていきたいです。