###### tags: `実装`

# 実装説明 Part2
今回の設計でのServiceLayerとは、前に説明の通りオニオンアーキテクチャのApplicationLayerとDomainLayerが一緒になったものです。

## 実装に入る前にやる事
1. 概念モデリングをして、データの関係を見つける（後でリファクタリングするので完璧じゃなくてもいい）
2. ユースケースを見つける

## Entityクラスの実装
概念モデリングで見つけたデータの関係を、Entityとして実装する。
ビジネスルールやロジックを実行するコンストラクタと単純な再構築をするコンストラクタに分ける。

## Repositoryインタフェースの定義
RepositoryはEntityクラス（Entityの中でもAggregateRootと呼ばれるもの）を保存or取得したり、Entityの永続化に関わる処理を実装するものです。
RepositoryインタフェースはInfrastructureLayerで実装します。
Repositoryの責務は以下のようなEntityの永続化に関わるものです。
- Entityの保存
- Entityの取得
- Entityの存在確認
- Entityにセットする値の取得

もしかしたら、Entityとは関係ない実装も混じっているかもしれませんが、責務が違うということになるので、Gatewayクラスに移動できないか検討する。

## UseCaseインタフェースの定義
UseCaseは、ユースケース分析で見つけた処理を定義したものです。
UseCaseインタフェースは同じServiceLayerにInteractorクラスとして実装します。
今回の設計では、開発期間があまりないということで、基本的にDomainModelで実装していますが、InteractorクラスでTxScriptのような手続きタイプの実装も行っても良いことにしています。
ApplicationLayerとDomainLayerが一緒になっている理由の一つに、UseCaseインタフェースの実装をTxScriptとDomainModelのどちらで行っても問題がないようにするというのがあります。
例えば、時間がないときはUseCaseの実装クラスのInteractorをTxScriptで実装して、リファクタリングでDomainModelに切り替えるということも可能ということです。

アプリケーションは常にリファクタリングしないと絶対に腐敗します。
つまり、リファクタリングやテストを前提とした設計が必要となります。

## Interactorの実装
Repositoryインタフェースを定義したので、InfrastractureLayerでRepositoryの実装クラスを作成したいところですが、その前に、UseCaseインタフェースの実装クラスであるInteractorを実装します。
これには理由があり、Repositoryインタフェースには必要と思われるメソッドを定義しただけで、実際にInteractorを実装すると足りないメソッドや必要ないメソッドが見つかるからです。
もしも、RepositoryインタフェースをInteractorの実装前に完璧に定義したい場合は、**ロバストネス分析**や**ユースケース記述**などでRepositoryで行う事を分析する必要がありますが、結構時間がかかるので、Interactorの実装の中で見つけていきましょう。

##### Entityオブジェクトの整合性のチェック
Entityが持っているデータだけでは（Entityの中だけでは）データの整合性を全てチェックすることはできません。
Entity以外で整合性をチェックする方法は以下のようなものがあります。
1. RepositoryでEntityオブジェクトのデータをチェックする
2. Validatorクラスを作成してオブジェクトをチェックする

> *注釈！ Validatorクラスを作成することで「xxxのチェックはしないといけないんだ！」というような強制力をモジュールに与えることができるし、クラス単体でValidationを表現できるという利点がある（責務をクラスに寄せることができる）*

## Interactorのテストを作成
Interactorの実装が完了したら、一旦PHPUnitでInteractorのテストを作成しましょう。
テストはユースケース単位で行います（結合テスト）
今回は、時間の都合上、ユースケース単位でテストしていますが、Entityだけでテストしたい場合は、別途Testクラスを作成しましょう。

## 今日のレビューポイント
今回のServiceLayerの実装でのレビューポイントは以下の通りです。

##### Layer間の依存の方向について違反がないか？
Layered Architectureでは、以下のような事を注意する必要があります。
1. 下のLayerは上のLayerに依存してはならない
2. 下のLayerから上のLayerに依存する場合は、インタフェースを利用して依存する
3. 下のLayerから上のLayerに依存しなければならない場合は、依存してもテストが容易が考える

##### EntityやRepositoryの凝集度（Cohesion）が高いか？
凝集度と単一責務原則（SOLID原則のSingle Responsibility）は似たような意味があります。
つまり、以下のような事に注意する必要があります。
- クラスの責務が一つの目的のためだけに作られているか？
- クラスに他の責務が入っていないか？
- クラスに他の責務が入っていた場合は、別のクラスとして作成できないか？

凝集度が低いクラスやメソッドはテストしにくいものです。
テストしにくいメソッドは、いつかバグの原因になります。
ただし、凝集度の高さについては、人それぞれ考え方が違うので、厳密なチェックはしなくて大丈夫です。