素人が2020年までの1ヶ月でLINE BOTに挑戦する毎日note. 【Day 20：DBスキーマの定義 part 4】

こんにちは！
12月1日から2019年残り1ヶ月でスケジュール調整BOTの開発に挑戦している"くろ"です。

最近NETFLIXを契約したので、作りながら久しぶりにテラスハウスを見ていたんですが、これ結構ハマっちゃいますね。笑

今東京編をやっているみたいで、Part 2の終わりくらい22話とかから見てたんですが、なんか前よりも全然人間ドラマ感が増している気がします。

恋愛だけじゃなくて、むしろヒューマンドラマとして、泣けるシーンや成長するシーン、本当に良い出会いをしたんだなーこの人達みたいなシーンがでてきて、結構ハマってしまって、結局最新の26話まで見ちゃってました。笑

ぺっぺとりょうの友情のシーンとか、はるかさんが成長した話とか、るか君が最後頑張ってみんなに感謝の気持ち伝えるのとか、本当に良かった。

めちゃくちゃミーハーなので、シェアハウスをしたくなりました。
誰かしてくれる人いたら教えて下さい。

はい。本題です。

BOTの概要：Day 2の記事

BOTの仕様：機能一覧やフローチャート Day 10の記事

昨日はDBスキーマの定義part 3として、作成したEntityにFB内容を反映しつつ、中身の解説をしました。

今日はEntityの次の段階として、「2，Repository」「3，Service logic」「4，Controller」について書いていきます。

まずはざっくり調べたことや教わったことを自分なりに理解した内容を書いていきます。

DBスキーマの定義

1，Entity
2，Repository
3，Service logic
4，Controller

1，Entityとは

Day14にも書きましたが、実体と呼ばれるものです。

具体的には、データの中で、1:1の関係に落とせないデータの単位がEntityです。
例えば、学校と学校名は1:1なので、Entity（箱）と属性（中身）の関係になるので、学校はEntity、学校名は属性となります。その箱同士（＝Entity同士）は学校と学生のように1:Nの関係で結ばれることでデータベースの構造ができていく。
それらを記述していくのが、Entityクラスになります。

2，Repositoryとは？

Repositoryクラスは、EntityのCreate（生成）、Read（読み取り）、Update（更新）、Delete（削除）を制御するための操作を定義するものです。

Entityクラスは単にEntityの構造を表しているだけなので、上記のような操作を定義してあげないと取り出したり作ったりできないってことらしいです。立つって何？話すって何？っていう赤ちゃんに立つってこれだよって教えてあげるようなものかなと思ってます。

その操作を定義しているのがRepositoryクラスということになります。

以下引用になります。
2の永続化云々は正直あまり分かってないですが、1のライフスタイルを制御する操作の定義は、普遍的な形で保存しておく必要があるということだと思っています。エンジニアの方間違ってたら教えて下さい。

Repositoryは、以下2つの役割を担う。
1，Serviceに対して、Entityのライフサイクルを制御するための操作（Repositoryインタフェース）を提供する。
Entityのライフサイクルを制御するための操作は、EntityオブジェクトへのCRUD操作となる。

2，Entityを永続化する処理(Repositoryインタフェースの実装クラス)を提供する。
Entityオブジェクトは、アプリケーションのライフサイクル(サーバの起動や、停止など)に依存しないレイヤに、永続化しておく必要がある。

https://terasolunaorg.github.io/guideline/public_review/ImplementationAtEachLayer/DomainLayer.html
※Javaという言語の記事なので、概念だけ拝借。

※CRUD（クラッド）とは、ほとんど全てのコンピュータソフトウェアが持つ永続性の4つの基本機能のイニシャルを並べた用語。 その4つとは、Create（生成）、Read（読み取り）、Update（更新）、Delete（削除）である。
https://ja.wikipedia.org/wiki/CRUD

3，Service logicとは？

とりあえずググります。

Serviceは、以下2つの役割を担う。

1，Controllerに対して業務ロジックを提供する。
業務ロジックは、アプリケーションで使用する業務データの参照、更新、整合性チェックおよびビジネスルールに関わる各種処理で構成される。
業務データの参照および更新処理をRepository(またはO/R Mapper)に委譲し、Serviceではビジネスルールに関わる処理の実装に専念することを推奨する。

2，トランザクション境界を宣言する。
データの一貫性を保障する必要がある処理（主にデータの更新処理）を行う業務ロジックの場合、トランザクション境界を宣言する。
データの参照処理の場合でも業務要件によっては、トランザクション管理が必要になる場合もあるので、その場合は、トランザクション境界を宣言する。
トランザクション境界は、原則Serviceに設ける。アプリケーション層(Web層)にトランザクション境界が設けられている場合、業務ロジックの抽出が正しく行われていない可能性があるので、見直しを行うこと。

ControllerとServiceで実装するロジックの責任分界点について
本ガイドラインでは、ControllerとServiceで実装するロジックは、以下のルールに則って実装することを推奨する。
1，クライアントからリクエストされたデータに対する単項目チェック、相関項目チェックはController側(Bean ValidationまたはSpring Validator)で行う。
2，Serviceに渡すデータへの変換処理(Bean変換、型変換、形式変換など)は、ServiceではなくController側で行う。
3，ビジネスルールに関わる処理はServiceで行う。業務データへのアクセスは、RepositoryまたはO/R Mapperに委譲する。
4，ServiceからControllerに返却するデータ（クライアントへレスポンスするデータ）に対する値の変換処理(型変換、形式変換など)は、Serviceではなく、Controller側（Viewクラスなど）で行う。

https://terasolunaorg.github.io/guideline/public_review/ImplementationAtEachLayer/DomainLayer.html

https://qiita.com/kuro227/items/a16e22ac12afe7442a3d
※これもJavaの記事ですが

ふーむ。これは結構分からない。笑

1つ1つ見ていきましょう。

Serviceは業務ロジックを作る所。
業務ロジックは、アプリケーションで使用する業務データの参照、更新、整合性チェックおよびビジネスルールに関わる各種処理で構成される。

ということなので、アプリケーションを構成するいろんなルールのロジックを規定する場所っぽい。アプリケーションの根幹ってことかなと。

さらに、師匠に教えてもらったことを踏まえると、

Repositoryが下位概念で、EntityのCreate（生成）、Read（読み取り）、Update（更新）、Delete（削除）をするだけのもの。

Service logicはその1つ上の概念で、Repositoryを利用しながら、ビジネスロジックを作るシステム。

Controllerはその上の概念で、Service logicを利用しながら、エンドユーザーからのアクションを受けて、リクエスト（ユーザー側のアクションによってシステムに求められるもの）を処理にマッピングし（交通整理みたいなものかな）、結果を戻すという画面遷移とセッション管理を行うもの。

4，Controller

1つ上で少し触れてしまいましたが、下記の記述も踏まえると、Controllerはユーザーのアクションに対して発生したリクエストを1つ1つの処理に分解して指示を出して、Service logicたちが処理を実行して戻ってきた結果を受けて、ユーザーに返す画面遷移とセッション管理してくれるような存在ぽいです。

基本的には、リクエストを処理にマッピングし、結果をViewに渡すという画面遷移と、セッション管理を担う。
https://terasolunaorg.github.io/guideline/public_review/Overview/ApplicationLayering.html#controller

なんとなーくですが、DBスキーマの定義を理解することができたかなと思います。

今日はここまでです。

明日もよろしくお願いします。