LaravelのMVCモデルからClean Architecture に変更した時のスライドです。 第8回福山IT座談会

1. Laravelでクリーンアーキテクチャ
まつあき

2. お品書き
• 自己紹介
• クリーンアーキテクチャ？
• サービスの紹介
• 改善案
• クリーンアーキテクチャにしていこう

3. Laravel 聞いたことある人～？

4. でしたら、省きますね

5. クリーンなシステムの設計って？

6. ソフトウェア開発は経験則？
• ハードウェアは、ムーアの法則の様に指数関数的に性能が向上す
るが
• ソフトウェアは、劇的な変化はなく、多くの成功事例から類推される
型（アーキテクチャ）として作り上げればいいのでは？
SOLID

7. SOLIDとは
• 単一責任の原則（個々の機能とモジュールは独立）
• オープンクローズドの原則（機能変更はコードの追加によって実装）
• リスコフの置換原則（個々のモジュールは交換可能）
• インターフェイス分離の原則（ＵＩとロジックは分離）
• 依存関係逆転の原則（上位の実装は下位のクラスに依存）

8. SOLIDとは
• 単一責任の原則（個々の機能とモジュールは独立）
• オープンクローズドの原則（機能変更はコードの追加によって実装）
• リスコフの置換原則（個々のモジュールは交換可能）
• インターフェイス分離の原則（ＵＩとロジックは分離）
• 依存関係逆転の原則（上位の実装は下位のクラスに依存）
どこの実装で上位下位の境界線を引くのか
→ アーキテクチャの決定

9. クリーンアーキテクチャ

10. クリーンアーキテクチャ概略（コーン型）

11. クリーンアーキテクチャ概略
1層目
コアとなるビジネスロジック
文字コード、時刻
2層目
ユースケース ビジネスロジック
掲示板モデル、バリデーションルール
3層目
UIとデータの橋渡し役
ビュー、コントローラー、その他出力
4層目
外部の詳細
フレームワークも含まれる

12. Laravel MVC（掲示板機能）
Boardモデル
Board View Board Controller
Board Table
モデルコントローラービュー
参照・リクエスト
値の返却
Laravel
レンダー
User

13. LaravelのMVCモデルから
クリーンアーキテクチャへ移行

14. 設計をし直す

15. Laravel MVC（掲示板機能）
Boardモデル
Board View Board Controller
Board Table
モデルコントローラービュー
参照・リクエスト
値の返却
Laravel
レンダー
User

16. 境界線を引く

17. Laravel MVC（掲示板機能）
Boardモデル
Board View Board Controller
Board Table
モデルコントローラービュー
参照・リクエスト
値の返却
Laravel
レンダー
User

18. 境界線を引く
Boardモデル
Board View Board Controller
Board Table
参照・リクエスト
値の返却
User
レンダー

19. あれ

20. 4層目から直接2層目に参照している

21. もっていく関係性
Boardモデル
Board View Board Controller
Board Table
参照・リクエスト
値の返却
User
レンダー

22. ユースケース、抽象クラスを追加

23. Presenter
Board
Controller
Board
Table
Use Case
Interactor
View
Model
Input
Boundary
< I >
Output
Boundary
< I >
Output Data
< DS >
Input Data
< DS >
Data Access
Data Access
Interface
Entities
View
< I >
< DS >
依存
汎化

24. えぇっ・・・

25. 例のあの図

26. 色付け

27. Presenter
Board
Controller
Board
Table
Use Case
Interactor
View
Model
Input
Boundary
< I >
Output
Boundary
< I >
Output Data
< DS >
Input Data
< DS >
Data Access
Data Access
Interface
Entities
View
< I >
< DS >

28. ＭＶＣモデルからの新規実装箇所

29. Presenter
Board
Controller
Board
Table
Use Case
Interactor
View
Model
Input
Boundary
< I >
Output
Boundary
< I >
Output Data
< DS >
Input Data
< DS >
Data Access
Data Access
Interface
Entities
View
< I >
< DS >

30. Presenter
Board
Controller
Board
Table
Use Case
Interactor
View
Model
Input
Boundary
< I >
Output
Boundary
< I >
Output Data
< DS >
Input Data
< DS >
Data Access
Data Access
Interface
Entities
View
< I >
< DS >
GRUD実装
OutputDataへの出力

31. 何がいいのか

32. クリーンアーキテクチャ
メリット
 レイヤーごとでテストができる
 フレームワークとの分離
デメリット
× 実装が煩雑になる
× フレームワークの便利な所に乗れない所がある(DIコンテナ、
Eloquent、ヘルパ等)

33. アーキテクチャを考えると
20
25
30
1 2 3
作業時間（分）
繰り返し回数
小規模プログラムの受け入れ
テスト完了までの制作時間
TDD 自由
同書のJ.Gorman の
実施結果より
リリースまでを考えた際には、
アーキテクチャを定められている
方が作業時間は結果的に少なく
なる。
（学習時間というコストを
前払いする必要があるが）

34. ありがとうございました

35. Presenter
Board
Controller
Board
Table
Use Case
Interactor
View
Model
Input
Boundary
< I >
Output
Boundary
< I >
Output Data
< DS >
Input Data
< DS >
Data Access
Data Access
Interface
Entities
View
< I >
< DS >

36. Board View
Board
Controller
Board
Table
Use Case
Interactor
View
Model
Input
Boundary
< I >
Output
Boundary
< I >
Output Data
< DS >
Input Data
< DS >
Data Access
Data Access
Interface
Entities
View