【phpcon2018 アウトプット】独立したコアレイヤパターンによる PHP アプリケーションの実装

独立したコアレイヤパターンによる PHP アプリケーションの実装

背景

なぜ独立したコアレイヤパターンを実装するのか

1. 対象ドメインが違うから

MVC + Service

• ユースケースをサービスとして切り出す
• Webアプリケーションの一部の’関心ごとは分離できた
  • HTTPに間することはサービスには入れない
• その他の技術詳細(RDBMS等)が分離できず

レイヤードアーキテクチャ

• ドメインを中心
• 分離はできるが、それなりに複雑
• もう少しシンプルにできないか

ベースのアイデア

• WhatとHowをレイヤで分ける
• コアロジックと技術詳細(フレームワーク含む)の分離
• 守るべきシンプルなルールのみを決める

独立したコアレイヤパターン

• アーキテクチャパターンの１つ
• ２つのレイヤに分離
• コアレイヤ
  • コアロジックを実装
• アプリケーションレイヤ (旧:サービスレイヤ)
  • HTTP/RDBMS/外部APIなどの技術詳細

コアレイヤ

• コアロジック (What) を実装
• Plain PHP
  • フレームワークに依存しない
  • データ構造や操作などの一部ライブラリは利用
• コアレイヤのみに依存
  • 技術詳細はインターフェイス経由で利用
• ユースケース、ドメインモデルなど

技術詳細インターフェイス

• コアレイヤが利用する技術詳細をインターフェイスで定義 　　 DBアクセス 　　 メール送信 　　* API呼び出し

• インターフェイスを実装したインスタンスをコアレイヤに渡す

要求をインターフェイスにする

• 実装の共通箇所をまとめるのではなく、必要な機能をインターフェイスにする方法
• 実装の数は問題ではない
• 依存関係逆転の法則(DIP)

依存関係逆転の放送

• Solid原則のD
• レイヤやモジュール間の依存関係をインターフェイスを利用して逆転させる

依存関係逆転の法則

ユースケースはインターフェイスに依存 アダプタがコアレイヤのインターフェイスに依存 * 依存関係が

アプリケーションレイヤ

• 技術詳細 (HOW) の実装

  • コアレイヤで定義したインターフェイスを実装
  • フレームワーク、ライブラリを活用

• UIからコアレイヤの実行

まとめ

• コアレイヤとアプリケーションレイヤに分離
• コアレイヤからアプリケーションレイヤはインターフェースを利用する

実装例

• https://github.com/shin1x1/phpcon2018-independent-core-layer

コアレイヤパターンの現場

レイヤわけに迷う

• 例: トランザクション 　　 トランザクション制御をインターフェース化 　　 実際のBEGIN/COMMIT/ROLLBACKはアプリケーションで実装

コアレイヤへの入出力データ

• ユースケースへの引数、戻り値のデータ型は自由
• スカラー型もしくはドメインモデルになる
  • フレームワーク固有の型は避ける
• 　例外: Laravel UploadedFile
  • APIテストには必要だったので妥協
  • PHPのアップロード機能自体が密結合 　

ルールの明確化

• 守れるシンプルなルールがある
  • コアレイヤ = フレームワークなし
  • アプリケーションレイヤ = フレームワークあり
• レビュー時の視点が定まる

まとめ

• コアレイヤとアプリケーションレイヤに分離
• コアレイヤからアプリケーションレイヤはインターフェースを利用してアクセス
• 依存関係逆転の法則
• フレームワーク、ライブラリは素晴らしい

全員がこのパターンをやるべきか？

• あくまで１つの考え
• フレームワーク密結合でも。その状況で最適と考えるならOK
• 引き出しに入れておく
• 銀の弾丸はない

質疑応答で出てきた用語

• CQRS