Slide 1
Slide 1 text
PHP でもアーキテクチャテスト
したい！
PHPerKaigi 2021
@kawanamiyuu
Slide 2
Slide 2 text
自己紹介
● かわなみゆう
● @kawanamiyuu
● 株式会社ラクス / Lead Engineer
● 人事・労務業務を楽にする SaaS の開発
● Spring Boot / Doma / Vue.js / Puppeteer / GitLab CI
● Java のほうから来ました。PHP がすきです。
2
Slide 3
Slide 3 text
今日話すこと
1. アーキテクチャ設計という営みの課題
2. アーキテクチャの正体とその問題点
3. アーキテクチャテストの紹介
4. アーキテクチャテストのその先
3
Slide 4
Slide 4 text
話さないこと
● PHP の各 Web アプリケーションフレームワークごとのアーキ
テクチャ設計のプラクティス
● 各アーキテクチャパターンの良し悪し
● 各アーキテクチャテストツールのより詳細な使い方
4
Slide 5
Slide 5 text
はじめに
5
Slide 6
Slide 6 text
Layered Architecture
（依存関係を逆転したレイヤードアーキテクチャ） 6
（一般的なレイヤードアーキテクチャ）
Slide 7
Slide 7 text
Clean Architecture
7
Slide 8
Slide 8 text
Independent Core Layer Pattern
8
https://blog.shin1x1.com/entry/independent-core-layer-pattern
Slide 9
Slide 9 text
Independent Core Layer Pattern
9
https://blog.shin1x1.com/entry/independent-core-layer-pattern
このあと
アーキテクチャテストの
サンプルがでてきます
Slide 10
Slide 10 text
アーキテクチャ設計という営みの課題
10
Slide 11
Slide 11 text
こんな悩みありませんか？
11
Slide 12
Slide 12 text
アーキテクトの悩み
● 開発初期に頑張って検討した設計方針が、納期優先・相次ぐ
メンバー増員により、いつのまにか泥団子に
● 開発プロセスとしてコードレビューは機能しているが、アーキテ
クチャの観点ではレビューされない
● 開発メンバーに設計力を上げてもらうためにチャレンジさせた
いけど、丸投げするのはちょっと不安
12
Slide 13
Slide 13 text
アーキテクトの悩み
● 開発初期に頑張って検討した設計方針が、納期優先・相次ぐ
メンバー増員により、いつのまにか泥団子に
● 開発プロセスとしてコードレビューは機能しているが、アーキテ
クチャの観点ではレビューされない
● 開発メンバーに設計力を上げてもらうためにチャレンジさせた
いけど、丸投げするのはちょっと不安
13
Slide 14
Slide 14 text
アーキテクトの悩み
● 開発初期に頑張って検討した設計方針が、納期優先・相次ぐ
メンバー増員により、いつのまにか泥団子に
● 開発プロセスとしてコードレビューは機能しているが、アーキテ
クチャの観点ではレビューされない
● 開発メンバーに設計力を上げてもらうためにチャレンジさせた
いけど、丸投げするのはちょっと不安
14
Slide 15
Slide 15 text
アーキテクトの悩み
● 開発初期に頑張って検討した設計方針が、納期優先・相次ぐ
メンバー増員により、いつのまにか泥団子に
● 開発プロセスとしてコードレビューは機能しているが、アーキテ
クチャの観点ではレビューされない
● 開発メンバーに設計力を上げてもらうためにチャレンジさせた
いけど、丸投げするのはちょっと不安
15
Slide 16
Slide 16 text
開発メンバーの悩み
● 新しくクラスを作るときにどこに置くべきか毎回迷う
● コードレビューで指摘されたけど、そんなルール聞いていな
し、ドキュメントもないので知りようがない
● ドメイン駆動設計？Clean Architecture？難しそうだし、ソー
スコードがどうあればそれらが適用されたアーキテクチャとい
えるのかイメージできない
16
Slide 17
Slide 17 text
開発メンバーの悩み
● 新しくクラスを作るときにどこに置くべきか毎回迷う
● コードレビューで指摘されたけど、そんなルール聞いていな
し、ドキュメントもないので知りようがない
● ドメイン駆動設計？Clean Architecture？難しそうだし、ソー
スコードがどうあればそれらが適用されたアーキテクチャとい
えるのかイメージできない
17
Slide 18
Slide 18 text
開発メンバーの悩み
● 新しくクラスを作るときにどこに置くべきか毎回迷う
● コードレビューで指摘されたけど、そんなルール聞いていな
し、ドキュメントもないので知りようがない
● ドメイン駆動設計？Clean Architecture？難しそうだし、ソー
スコードがどうあればそれらが適用されたアーキテクチャとい
えるのかイメージできない
18
Slide 19
Slide 19 text
開発メンバーの悩み
● 新しくクラスを作るときにどこに置くべきか毎回迷う
● コードレビューで指摘されたけど、そんなルール聞いていな
し、ドキュメントもないので知りようがない
● ドメイン駆動設計？Clean Architecture？難しそうだし、ソー
スコードがどうあればそれらが適用されたアーキテクチャとい
えるのかイメージできない
19
Slide 20
Slide 20 text
悩みの原因
● アーキテクチャ設計に関する知識が属人化している
● アーキテクチャ設計に関する知識が暗黙知化している
● 知っている人が人力でチェックするしかない
● 知らなければ当然、チェックされることなくすり抜けてしまう
20
Slide 21
Slide 21 text
悩みの原因
● アーキテクチャ設計に関する知識が属人化している
● アーキテクチャ設計に関する知識が暗黙知化している
● 知っている人が人力でチェックするしかない
● 知らなければ当然、チェックされることなくすり抜けてしまう
21
Slide 22
Slide 22 text
悩みの原因
● アーキテクチャ設計に関する知識が属人化している
● アーキテクチャ設計に関する知識が暗黙知化している
● 知っている人が人力でチェックするしかない
● 知らなければ当然、チェックされることなくすり抜けてしまう
22
ソースコードの品質担保以上に、アーキテクチャの品質担保は難しい
Slide 23
Slide 23 text
「アーキテクチャ」の正体
23
Slide 24
Slide 24 text
Layered Architecture
（依存関係を逆転したレイヤードアーキテクチャ） 24
（一般的なレイヤードアーキテクチャ）
Slide 25
Slide 25 text
Layered Architecture
（〇〇〇〇を逆転したレイヤードアーキテクチャ） 25
（一般的なレイヤードアーキテクチャ）
Slide 26
Slide 26 text
Clean Architecture
26
Slide 27
Slide 27 text
Clean Architecture
27
Slide 28
Slide 28 text
依存関係
28
Slide 29
Slide 29 text
アーキテクチャとは
「依存関係」のガイドライン
29
Slide 30
Slide 30 text
アーキテクチャの正体
● アーキテクチャとはソフトウェアの構造についての取り決めで
あり、
● 解像度を上げていくと、ソフトウェアを構成する責務や関心事
の「依存関係」についての取り決め
● （乱暴に言うと）Layered Architecture も Clean
Architecture も 、DDD のような設計論も、依存関係を適切
に設計したいだけ
30
Slide 31
Slide 31 text
「アーキテクチャ」の問題点
31
Slide 32
Slide 32 text
「ガイドライン」というものの性質
● ガイドラインとは「指針」「ルール」「マナー」
● 人が決めて、守る（守らせる）
● 最初にルールをつくるのは、簡単
● ルール通りつくり始めるのも、簡単
32
Slide 33
Slide 33 text
「ガイドライン」というものの性質
● ガイドラインとは「指針」「ルール」「マナー」
● 人が決めて、守る（守らせる）
● 最初にルールをつくるのは、簡単
● ルール通りつくり始めるのも、簡単
なにが難しいのか？
33
Slide 34
Slide 34 text
「ガイドライン」というものの性質
● ガイドラインとは「指針」「ルール」「マナー」
● 人が決めて、守る（守らせる）
● 最初にルールをつくるのは、簡単
● ルール通りつくり始めるのも、簡単
なにが難しいのか？
34
アーキテクチャの維持が難しい。
人が決めたものであるがゆえ、壊れやすい。
Slide 35
Slide 35 text
PHP ならではの問題
● クラスはすべて公開（public）
● クラスのメソッドも公開（public）か非公開（protected,
private）のみ
● 言語仕様レベルで依存関係をコントロールできない
35
Slide 36
Slide 36 text
他のプログラミング言語では
● 例えば Java ではクラスやメソッドの可視性をパッケージプライ
ベートにできる
○ PHP 風に言うと、可視性を名前空間内に限定できる
● 言語仕様レベルである程度、依存関係をコントロールできる
● が、やはり十分ではない
36
Slide 37
Slide 37 text
どうすればよいか？
37
Slide 38
Slide 38 text
38
アーキテクチャをテストしたい
Slide 39
Slide 39 text
アーキテクチャテストの紹介
39
Slide 40
Slide 40 text
アーキテクチャテスト を一言でいうと
● アプリケーションを構成するクラスの依存関係や、アプリケー
ション固有の実装ルールをコードとして表現し、自動テストする
こと
● コード化により、設計に関する暗黙知が形式知化される
● 自動化により、一定の強制力をもってアーキテクチャの設計品
質を担保し続けることができる
40
Slide 41
Slide 41 text
アーキテクチャテスト を一言でいうと
● アプリケーションを構成するクラスの依存関係や、アプリケー
ション固有の実装ルールをコードとして表現し、自動テストする
こと
● コード化により、設計に関する暗黙知が形式知化される
● 自動化により、一定の強制力をもってアーキテクチャの設計品
質を担保し続けることができる
41
Slide 42
Slide 42 text
アーキテクチャテスト を一言でいうと
● アプリケーションを構成するクラスの依存関係や、アプリケー
ション固有の実装ルールをコードとして表現し、自動テストする
こと
● コード化により、設計に関する暗黙知が形式知化される
● 自動化により、一定の強制力をもってアーキテクチャの設計品
質を担保し続けることができる
42
Slide 43
Slide 43 text
アーキテクチャテスト を一言でいうと
● アプリケーションを構成するクラスの依存関係や、アプリケー
ション固有の実装ルールをコードとして表現し、自動テストする
こと
● コード化により、設計に関する暗黙知が形式知化される
● 自動化により、一定の強制力をもってアーキテクチャの設計品
質を担保し続けることができる
43
Slide 44
Slide 44 text
アーキテクチャテスト・フレームワーク
● sensiolabs-de/deptrac（PHP）
● carlosas/phpat（PHP）
● nazonohito51/dependency-analyzer（PHP）
● TNG/ArchUnit（Java）
● TNG/ArchUnitNET（C#）
● MaibornWolff/ts-arch（TypeScript）
44
Slide 45
Slide 45 text
アーキテクチャテスト・フレームワーク
● sensiolabs-de/deptrac（PHP）
● carlosas/phpat（PHP）
● nazonohito51/dependency-analyzer（PHP）
● TNG/ArchUnit（Java）
● TNG/ArchUnitNET（C#）
● MaibornWolff/ts-arch（TypeScript）
45
この 2 つのテストフレーム
ワークを紹介します。
Slide 46
Slide 46 text
46
（本日のお題）
独立したコアレイヤーパターン
のアーキテクチャテスト
Slide 47
Slide 47 text
アーキテクチャテストの
サンプルコード
47
https://github.com/kawanamiyuu/independent-core-layer-architecture-test
Slide 48
Slide 48 text
deptrac でのアーキテクチャテスト
48
Slide 49
Slide 49 text
deptrac の特徴
● 名前空間やディレクトリを layer と捉えて、layer に含まれるの
クラスの依存関係をテストできる
● YAML ファイルに layer の依存関係の rule を定義する
● 依存を「許可する」意味のテストがしやすい
49
Slide 50
Slide 50 text
Demo (1)
50
Slide 51
Slide 51 text
phpat でのアーキテクチャテスト
51
Slide 52
Slide 52 text
phpat の特徴
● メソッドチェーンを利用した DSL（fluent interface）によりアー
キテクチャテストをコードとして実装する
● 単純な依存関係だけでなく、クラスが期待するインターフェイス
を implements しているか、というような実装ルールもチェッ
クできる
● 依存を「禁止する」意味のテストがしやすい
52
Slide 53
Slide 53 text
Demo (2)
53
Slide 54
Slide 54 text
アーキテクチャテストのその先
54
Slide 55
Slide 55 text
アーキテクチャテストの失敗は悪か？
● アーキテクチャテストはあるべき依存関係を表現したもの
● アーキテクチャテストは失敗しないはずのテスト
● アーキテクチャテストが失敗するとき
○ 実装誤り
○
○
55
Slide 56
Slide 56 text
アーキテクチャテストの失敗は悪か？
● アーキテクチャテストはあるべき依存関係を表現したもの
● アーキテクチャテストは失敗しないはずのテスト
● アーキテクチャテストが失敗するとき
○ 実装誤り
○ アーキテクチャに対する発見のサイン
○ アーキテクチャについて議論する始点
56
Slide 57
Slide 57 text
アーキテクチャを育てる
● ドメイン駆動設計が設計⇔実装のフィードバックループを重視
するのと同じく
● アーキテクチャも一度決めて終わりではない
● ソフトウェアの成長の過程で、アーキテクチャに対してもフィー
ドバックを得て、適切な依存関係を発見していく必要がある
57
Slide 58
Slide 58 text
アーキテクチャを育てる
● ドメイン駆動設計が設計⇔実装のフィードバックループを重視
するのと同じく
● アーキテクチャも一度決めて終わりではない
● ソフトウェアの成長の過程で、アーキテクチャに対してもフィー
ドバックを得て、適切な依存関係を発見していく必要がある
58
Slide 59
Slide 59 text
アーキテクチャの進化を支える
● 境界づけられたコンテキストやドメインのあるべき依存関係に
向き合い続ける
● モジュラーモノリスの実現
● マイクロサービスアーキテクチャへ発展可能性
59
Slide 60
Slide 60 text
アーキテクチャの進化を支える
● 境界づけられたコンテキストやドメインのあるべき依存関係に
向き合い続ける
● モジュラーモノリスの実現
● マイクロサービスアーキテクチャへ発展可能性
60
Slide 61
Slide 61 text
今日話したこと
1. アーキテクチャ設計という営みの課題
○ アーキテクチャ設計品質の担保の難しさ
2. アーキテクチャの正体とその問題点
○ アーキテクチャは「依存関係のガイドライン」
3. アーキテクチャテストの紹介
4. アーキテクチャテストのその先
○ アーキテクチャテストが、アーキテクチャを育て、発展させる
61
Slide 62
Slide 62 text
今日話したこと
1. アーキテクチャ設計という営みの課題
○ アーキテクチャ設計品質の担保の難しさ
2. アーキテクチャの正体とその問題点
○ アーキテクチャは「依存関係のガイドライン」
3. アーキテクチャテストの紹介
4. アーキテクチャテストのその先
○ アーキテクチャテストが、アーキテクチャを育て、発展させる
62
Slide 63
Slide 63 text
PHP でも
アーキテクチャテスト、
やっていきましょう！
63
Slide 64
Slide 64 text
（Appendix）アーキテクチャテストに関する過去の登壇資料など
● ArchUnit で Java アプリケーションのアーキテクチャを CI する / JJUG CCC 2019 Spring
○ https://speakerdeck.com/kawanamiyuu/jjug-ccc-2019-spring
● ドメイン駆動設計を支えるアーキテクチャテスト / Object-Oriented Conference 2020
○ https://speakerdeck.com/kawanamiyuu/object-oriented-conference-2020
● マイクロサービスアーキテクチャをあきらめないための、モノリスで始めるアーキテクチャテスト /
JJUG CCC 2020 Fall
○ https://speakerdeck.com/kawanamiyuu/jjug-ccc-2020-fall
● アーキテクチャテスト Advent Calendar 2020
○ https://qiita.com/advent-calendar/2020/architecture-test
64