設計の考え方 - インターフェースと腐敗防止層編 #phpconfuk / Interface and Anti Corruption Layer

2024/06/22 開催の「PHP カンファレンス福岡 2024」（https://phpcon.fukuoka.jp/2024/ ）のトーク資料です。

詳細：https://fortee.jp/phpcon-fukuoka-2024/proposal/25f1e7b5-937f-4de9-a6de-b78fc9efd71c

Transcript

1. 設計の考え方 インターフェースと腐敗防止層編 2024/06/22 PHP カンファレンス福岡 2024
2. 所属：株式会社ウィルゲート 登壇： 寄稿： 岡田 正平／おかしょい X: @okashoi GitHub: @okashoi
3. 本セッションは以下を満たす人を想定聴講者としています • PHP のコードは一通り書ける（フレームワーク上でも可） • 機能追加等によって、実装上の設計を考える必要がある （考えたことがある） • クラスベースのオブジェクト指向プログラミングにおける 「継承」等の挙動はわかる おことわり
4. 「腐敗防止層」という考え方 • 原典から簡略化して、コンセプトだけ説明 • システムを長生きさせるために意識したいこと このセッションで伝えること 出典： Eric Evans.『エリック・エヴァンスのドメイン駆動設計』(p.376). 翔泳社. Kindle 版.
5. • ライブラリを使うときに何を考慮するか • PHP であれば Composer、JavaScript であれば npm など でインストールするもの 考えてみよう
6. php-ulid というライブラリを使ったコード • ULID とは全世界で一意かつソート可能な識別子 • 注：php-ulid であることに特に意味はない （ライブラリを使ったコードなら何でもよかった） https://github.com/robinvdvleuten/php-ulid 課題設定 1
7. ① そのまま php-ulid を使った例 <?php use Ulid\Ulid; readonly class User { private function __construct( public string $id, public string $name, ) { } public static function create(string $name): static { $id = (string)Ulid::generate(); return new User($id, $name); } }
8. <?php use Ulid\Ulid; readonly class User { private function __construct( public string $id, public string $name, ) { } public static function create(string $name): static { $id = (string)Ulid::generate(); return new User($id, $name); } } ① そのまま php-ulid を使った例
9. ② 1 枚薄い wrapper を噛ませた例 <?php namespace MyUlid; use Ulid\Ulid; function ulid(): string { return (string)Ulid::generate(); }
10. ② 1 枚薄い wrapper を噛ませた例 <?php namespace MyUlid; use Ulid\Ulid; function ulid(): string { return (string)Ulid::generate(); }
11. ② 1 枚薄い wrapper を噛ませた例 <?php namespace MyUlid; use Ulid\Ulid; function ulid(): string { return (string)Ulid::generate(); } <?php use function MyUlid\ulid; readonly class User { private function __construct( public string $id, public string $name, ) { } public static function create(string $name): static { $id = ulid(); return new User($id, $name); } }
12. ② 1 枚薄い wrapper を噛ませた例 <?php namespace MyUlid; use Ulid\Ulid; function ulid(): string { return (string)Ulid::generate(); } <?php use function MyUlid\ulid; readonly class User { private function __construct( public string $id, public string $name, ) { } public static function create(string $name): static { $id = ulid(); return new User($id, $name); } }
13. どうしてわざわざそんなことを......？
14. そのまま使った例（ケース①）の現状 php-ulid User uses
15. User 以外にも ULID で採番していくとこう php-ulid User uses Post Comment …… uses uses uses
16. 「そのとき」はやってくる • ライブラリのバージョンアップ • ライブラリに深刻な不具合が見つかった • ライブラリがメンテナンスされなくなった • 別のライブラリの方が性能が良いことが分かった ......etc. そしてある日...... ※あくまで例えなので php-ulid がそれに該当するという話ではない
17. 影響範囲は利用箇所すべてに及ぶ php-ulid User uses Post Comment …… uses uses uses
18. 影響範囲は利用箇所すべてに及ぶ php-ulid User uses Post Comment …… uses uses uses
19. wrapper を噛ませていた場合（ケース②） MyUlid User uses php-ulid uses
20. 同様に増えていっても MyUlid User uses php-ulid uses Post Comment …… uses uses uses
21. 同様に増えていっても MyUlid User uses php-ulid uses Post Comment …… uses uses uses
22. 影響は wrapper までに留められる（※） MyUlid User uses php-ulid uses Post Comment …… uses uses uses ※ただし wrapper のインターフェース　 が変わらない前提
23. ライブラリに限らず、以下についても当てはまる • フレームワークの機能 • データベースとのやりとり • 外部システムとのやりとり（Web API 等経由） この役割が「腐敗防止層」
24. 影響は wrapper までに留められる（※） MyUlid User uses php-ulid uses Post Comment …… uses uses uses ※ただし wrapper のインターフェース　 が変わらない前提
25. 影響は wrapper までに留められる（※） MyUlid User uses php-ulid uses Post Comment …… uses uses uses ※ただし wrapper のインターフェース　 が変わらない前提
26. ここで言う「インターフェース」には 2 つの意味がある 広義のインターフェース = API（Application Programming Interface） 狭義のインターフェース = プログラミング言語の機能として提供される抽象型 「インターフェース」とは
27. API（Application Programming Interface） • 関数であれば引数と戻り値など • 作り手と使い手の間の「決めごと」 • 「仕様」と言い換えてもよい 広義のインターフェース
28. プログラミング言語の機能として提供される抽象型 狭義のインターフェース <?php namespace Psr\Http\Client; use Psr\Http\Message\RequestInterface; use Psr\Http\Message\ResponseInterface; interface ClientInterface { /** * Sends a PSR-7 request and returns a PSR-7 response. * //（略） */ public function sendRequest(RequestInterface $request): ResponseInterface; }
29. 設計における重要な判断 以下のようなインターフェースは避けたい • 依存ライブラリの変更が、利用する側にも影響してしまう • 実装の詳細を知らないと正しく使えない （広義の）インターフェースをどう定めるか？
30. 所定の形式で HTTP リクエストを行う処理がある • 実際の HTTP リクエスト部分には Guzzle を用いる • wrapper を噛ませて利用者は Guzzle を意識しないよ うにしたい https://github.com/guzzle/guzzle 課題設定 2
31. GuzzleHttp\ClientTrait /** * Create and send an HTTP GET request. * * Use an absolute path to override the base path of the client, or a * relative path to append to the base path of the client. The URL can * contain the query string as well. * * @param string|UriInterface $uri URI object or string. * @param array $options Request options to apply. * * @throws GuzzleException */ public function get($uri, array $options = []): ResponseInterface { return $this->request('GET', $uri, $options); }
32. • 第三者が定める標準を利用できないか検討する • 自分たちで設計する場合は対象を「抽象化」する • 利用する側が、内部実装や依存ライブラリの詳細を 意識しなくても良いようにする • 公開する操作を使うものだけに絞る （広義の）インターフェースをどう定めるか？
33. • 第三者が定める標準を利用できないか検討する • 自分たちで設計する場合は対象を「抽象化」する • 利用する側が、内部実装や依存ライブラリの詳細を 意識しなくても良いようにする • 公開する操作を使うものだけに絞る （広義の）インターフェースをどう定めるか？
34. GuzzleHttp\ClientTrait /** * Create and send an HTTP GET request. * * Use an absolute path to override the base path of the client, or a * relative path to append to the base path of the client. The URL can * contain the query string as well. * * @param string|UriInterface $uri URI object or string. * @param array $options Request options to apply. * * @throws GuzzleException */ public function get($uri, array $options = []): ResponseInterface { return $this->request('GET', $uri, $options); } URI の文字列か、PSR に則っているので ここはそのまま使うという選択肢は充分ありえる
35. PHP-FIG という組織が定める「標準勧告」 • オートローディングに関する仕様（PSR-4） • コーディングスタイル（PSR-1、PSR-12） • インターフェース（上記以外） あくまで第三者組織による「勧告」であり、強制力を 持つものではない 補足：PSR（PHP Standards Recommendations）
36. 補足：PSR（PHP Standards Recommendations） https://www.php-fig.org/psr/
37. • 第三者が定める標準を利用できないか検討する • 自分たちで設計する場合は対象を「抽象化」する • 利用する側が、内部実装や依存ライブラリの詳細を 意識しなくても良いようにする • 公開する操作を使うものだけに絞る インターフェースをどのように定めるか？
38. GuzzleHttp\ClientTrait /** * Create and send an HTTP GET request. * * Use an absolute path to override the base path of the client, or a * relative path to append to the base path of the client. The URL can * contain the query string as well. * * @param string|UriInterface $uri URI object or string. * @param array $options Request options to apply. * * @throws GuzzleException */ public function get($uri, array $options = []): ResponseInterface { return $this->request('GET', $uri, $options); }
39. このような wrapper を噛ませても <?php use GuzzleHttp\Client; class MyHttpClient { public function get(string $url): string { $response = (new Client())->get($url); return $response->getBody()->getContents(); } }
40. 実際に使おうとすると <?php use GuzzleHttp\Exception\GuzzleException; readonly class SomeService { public function __construct(private MyHttpClient $client) { } public function getSomeDataFromWeb(string $url): string { try { $responseBody = $this->client->get($url); } catch (GuzzleException) { // なんらかのエラー処理 } // 後続処理 } }
41. まだ GuzzleHttp へ直接依存してしまっている <?php use GuzzleHttp\Exception\GuzzleException; readonly class SomeService { public function __construct(private MyHttpClient $client) { } public function getSomeDataFromWeb(string $url): string { try { $responseBody = $this->client->get($url); } catch (GuzzleException) { // なんらかのエラー処理 } // 後続処理 } }
42. GuzzleHttp\ClientTrait /** * Create and send an HTTP GET request. * * Use an absolute path to override the base path of the client, or a * relative path to append to the base path of the client. The URL can * contain the query string as well. * * @param string|UriInterface $uri URI object or string. * @param array $options Request options to apply. * * @throws GuzzleException */ public function get($uri, array $options = []): ResponseInterface { return $this->request('GET', $uri, $options); } GuzzleHttp 固有の例外なので 腐敗防止層では適切にハンドリングして • PHP 組み込みの例外に変換 • 独自定義の例外に変換 • 正常系として適切に処理 等の対応をしておきたい
43. • 第三者が定める標準を利用できないか検討する • 自分たちで設計する場合は対象を「抽象化」する • 利用する側が、内部実装や依存ライブラリの詳細を 意識しなくても良いようにする • 公開する操作を使うものだけに絞る インターフェースをどのように定めるか？
44. GuzzleHttp\ClientTrait /** * Create and send an HTTP GET request. * * Use an absolute path to override the base path of the client, or a * relative path to append to the base path of the client. The URL can * contain the query string as well. * * @param string|UriInterface $uri URI object or string. * @param array $options Request options to apply. * * @throws GuzzleException */ public function get($uri, array $options = []): ResponseInterface { return $this->request('GET', $uri, $options); }
45. GuzzleHttp\ClientTrait /** * Create and send an HTTP GET request. * * Use an absolute path to override the base path of the client, or a * relative path to append to the base path of the client. The URL can * contain the query string as well. * * @param string|UriInterface $uri URI object or string. * @param array $options Request options to apply. * * @throws GuzzleException */ public function get($uri, array $options = []): ResponseInterface { return $this->request('GET', $uri, $options); } 確かに型情報としてはGuzzleHttpに依存していないが......
46. 実態はライブラリ詳細 → wrapper を噛ませる場合は 　ユースケースにあわせて 　隠蔽しておきたいもの
47. • 第三者が定める標準を利用できないか検討する • 自分たちで設計する場合は対象を「抽象化」する • 利用する側が、内部実装や依存ライブラリの詳細を 意識しなくても良いようにする • 公開する操作を使うものだけに絞る インターフェースをどのように定めるか？
48. • 依存関係を逆転させられる • 具象（実装）を動的に切り替えられる • 継承とは別の切り口で多態性を実現できる ※単に「腐敗防止層」を実現するだけであれば必ずしも　 使う必要はない （狭義の）インターフェースを使う利点
49. • 依存関係を逆転させられる • 具象（実装）を動的に切り替えられる • 継承とは別の切り口で多態性を実現できる ※単に「腐敗防止層」を実現するだけであれば必ずしも　 使う必要はない （狭義の）インターフェースを使う利点
50. Laravel の config/session.php 具象（実装）を動的に切り替えられる https://github.com/laravel/framework/blob/02a0b5f6f83b13ea750f959364aefa324441a 354/config/session.php
51. 具象（実装）を動的に切り替えられる https://www.php.net/SessionHandlerInterface
52. 我々はこの端子の形を見て USB（Type-A）だと認識する 身近な抽象化、インターフェース
53. 充電をするために両端の電気的特性を調べる必要はない → 利用者に詳細を意識させていないつくり 身近な抽象化、インターフェース
54. 裏にある詳細を隠蔽する仕組み • HTTP • TCP/IP • VM • コンパイラ • ......etc. 利用者が専門知識を持たずとも便利に暮らせるのは インターフェースが適切に設計されているから 身近な抽象化、インターフェース
55. 「腐敗防止層」という考え方 • 原典から簡略化して、コンセプトだけ説明 • システムを長生きさせるために意識したいこと このセッションで伝えること（再掲） 出典： Eric Evans.『エリック・エヴァンスのドメイン駆動設計』(p.376). 翔泳社. Kindle 版.