擬人化で完全に理解するクリーンアーキテクチャ

PHPカンファレンス関西2024 の発表資料になります

Transcript

1. 擬人化で完全に理解する クリーンアーキテクチャ 2024/02/11 ペチコン関西2024 by しまぶ@shimabox 

2. 自己紹介
3. Clean Architecture 達人に学ぶソフトウェアの構造と設計 はじめに • これからお話しすることは、この本を 読んで得た自分なりの理解に基づいて います • 発表内容で出てくる用語や概念につい ては、ほぼほぼこの本の内容と自分の 個人的な解釈が混ざり合っていると考 えてください ※ 他には`ちょうぜつソフトウェア設計入門`など から知識を得ています
4. 1. 各レイヤーの概要 2. 擬人化してみる 3. クリーンアーキテクチャって？ 4. まとめ アジェンダ
5. 1. 各レイヤーの概要 2. 擬人化してみる 3. クリーンアーキテクチャって？ 4. まとめ アジェンダ
6. 1. 各レイヤーの概要 クリーンアーキテクチャと言えば？ • エンティティ　 ◦ ちょうぜつだと、ドメインモデル ◦ 最上位、一番内側 と言われる • ユースケース　 • インターフェイスアダプター　 • フレームワークとドライバー　 ◦ ちょうぜつだと、インフラストラク チャー ◦ 最下位、一番外側 と言われる
7. 1. 各レイヤーの概要 クリーンアーキテクチャと言えば？上位、下位って？ • エンティティ　 ◦ ちょうぜつだと、ドメインモデル ◦ 最上位、一番内側 と言われる • ユースケース　 • インターフェイスアダプター　 • フレームワークとドライバー　 ◦ ちょうぜつだと、インフラストラク チャー ◦ 最下位、一番外側 と言われる
8. 1. 各レイヤーの概要 クリーンアーキテクチャと言えば？上位、下位って？ • エンティティ　 ◦ ちょうぜつだと、ドメインモデル ◦ 最上位、一番内側 と言われる • ユースケース　 • インターフェイスアダプター　 • フレームワークとドライバー　 ◦ ちょうぜつだと、インフラストラク チャー ◦ 最下位、一番外側 と言われる あくまでもイメージ
9. 1. 各レイヤーの概要 エンティティ(ドメインモデル) • 企業のビジネスルール(方針) • 業務そのもの • これだけでも成り立つ • ビジネスロジック ◦ 人間が考えるところ → 高レイヤー • 最重要
10. 1. 各レイヤーの概要 ユースケース • アプリケーション固有のビジネスルール • エンティティ(最重要ビジネスルール)を組み合わせてやり たいことを達成する • 何ができるのかの部分 • 内部
11. 1. 各レイヤーの概要 インターフェイスアダプター • 外部と内部との仲介役 • 外部の要求を内部に伝える • 内部からの返答を外部に返す • 関心ごとの変換 • Controller, Gateway, Presenter
12. 1. 各レイヤーの概要 フレームワークとドライバー(インフラストラクチャー) • フレームワーク, UI, DB, API, テスト, 外部ライブラリ な どなど • 詳細(些細なもの) ◦ プログラムの本質的な目的に直接は貢献しないが、そ れを実現するために必要な技術的なツールや仕組み ◦ 技術詳細 ◦ 技術(機械)に任せる → 低レイヤー • 外部
13. 1. 各レイヤーの概要 クリーンアーキテクチャと言えば？ 登場するのはこの4つのレイヤー (荒ぶってはいない)
14. 1. クリーンアーキテクチャについて 2. 擬人化してみる 3. クリーンアーキテクチャって？ 4. まとめ 2. 擬人化してみる
15. 2. 擬人化してみる レイヤーそのものを擬人化してみようと思ったが...
16. 2. 擬人化してみる レイヤーそのものを擬人化してみようと思ったが... 挫折
17. 2. 擬人化してみる レイヤーそのものを擬人化してみようと思ったが... シナリオを考える必要がある
18. 2. 擬人化してみる シナリオを考えてみた バンド(ミュージシャン)が 曲をリリースする
19. 2. 擬人化してみる 某バンド(Bump of Kitchen)を題材に考えてみた
20. 2. 擬人化してみる 某バンド(Bump of Kitchen)を題材に考えてみた やっぱり無茶がある 😇
21. 2. 擬人化してみる なぜ無茶があるのか • そもそもの誤解がある ◦ レイヤーをこの4つに分割しろとは言っていない、そんなルールはない • この4つのレイヤーの役割も抽象的 ◦ 中にも色々な役割/概念がある、擬人化で具体化するのは無謀 • ソースコードの依存性は常に内側(上位レベルの方針)にむける • 方針(上位)を頑張って決めて、詳細(下位)の決定を遅らせろ • 究極、この2つのことしか言っていない
22. 2. 擬人化してみる なぜ無茶があるのか • そもそもの誤解がある ◦ レイヤーをこの4つに分割しろとは言っていない、そんなルールはない • この4つのレイヤーの役割も抽象的 ◦ 中にも色々な役割/概念がある、擬人化で具体化するのは無謀 • ソースコードの依存性は常に内側(上位レベルの方針)にむける • 方針(上位)を頑張って決めて、詳細(下位)の決定を遅らせろ • 究極、この2つのことしか言っていない • 4つのレイヤーにそこまで触れていない！！
23. • そもそもの誤解がある ◦ レイヤーをこの4つに分割しろとは言っていない、そんなルールはない • この4つのレイヤーの役割も抽象的 ◦ 中にも色々な役割/概念がある、擬人化で具体化するのは無謀 • ソースコードの依存性は常に内側(上位レベルの方針)にむける • 方針(上位)を頑張って決めて、詳細(下位)の決定を遅らせろ • 究極、この2つのことしか言っていない • 4つのレイヤーにそこまで触れていない！！ 2. 擬人化してみる なぜ無茶があるのか
24. 2. 擬人化してみる じゃあ、クリーンアーキテ クチャってなんだろう？
25. 1. クリーンアーキテクチャについて 2. 擬人化してみる 3. クリーンアーキテクチャって？ 4. まとめ 3. クリーンアーキテクチャって？
26. 2. 擬人化してみる 3. クリーンアーキテクチャって？ 実装例を見てみる • エンティティ　 ◦ ちょうぜつだと、ドメインモデル ◦ 最上位、一番内側 と言われる • ユースケース　 • インターフェイスアダプター　 • フレームワークとドライバー　 ◦ ちょうぜつだと、インフラストラク チャー ◦ 最下位、一番外側 と言われる
27. 2. 擬人化してみる 3. クリーンアーキテクチャって？ 実装例を見てみる • エンティティ　 ◦ ちょうぜつだと、ドメインモデル ◦ 最上位、一番内側 と言われる • ユースケース　 • インターフェイスアダプター　 • フレームワークとドライバー　 ◦ ちょうぜつだと、インフラストラク チャー ◦ 最下位、一番外側 と言われる
28. 2. 擬人化してみる 3. クリーンアーキテクチャって？ 実装例を見てみる • エンティティ　 ◦ ちょうぜつだと、ドメインモデル ◦ 最上位、一番内側 と言われる • ユースケース　 • インターフェイスアダプター　 • フレームワークとドライバー　 ◦ ちょうぜつだと、インフラストラク チャー ◦ 最下位、一番外側 と言われる ここらへんが 重要なところ (エンティ ティが一番重 要だけど)
29. 2. 擬人化してみる 3. クリーンアーキテクチャって？ 実装例を見てみる • エンティティ　 ◦ ◦ • ユースケース　 • インターフェイスアダプター　 • フレームワークとドライバー　
30. 2. 擬人化してみる 3. クリーンアーキテクチャって？ 実装例を見てみる • エンティティ　 ◦ ◦ • ユースケース　 • インターフェイスアダプター　 • フレームワークとドライバー　
31. 2. 擬人化してみる 3. クリーンアーキテクチャって？ 実装例を見てみる • エンティティ　 ◦ ◦ • ユースケース　 • インターフェイスアダプター　 • フレームワークとドライバー　
32. • エンティティ　 ◦ ちょうぜつだと、ドメインモデル ◦ 最上位、一番内側 と言われる • ユースケース　 • インターフェイスアダプター　 • フレームワークとドライバー　 ◦ ちょうぜつだと、インフラストラク チャー ◦ 最下位、一番外側 と言われる ソースコードの依存性は、内側 (上位レベルの方針) だけに向かっていかなくてはならない 3. クリーンアーキテクチャって？ 実装例を見てみる
33. 2. 擬人化してみる 3. クリーンアーキテクチャって？ 実装例を見てみる
34. なぜ依存の向きにこだわるのか 3. クリーンアーキテクチャって？ • Fooは安定度が低い Baz Bar Foo ・・・
35. なぜ依存の向きにこだわるのか 3. クリーンアーキテクチャって？ • Fooは安定度が低い • Barなどに変更が入るとFooに影響 が出る • FooはBarのことを知っている • FooはBarに依存する Baz Bar Foo ・・・ ❌ 変更 ❌ 影響
36. なぜ依存の向きにこだわるのか 3. クリーンアーキテクチャって？ • Fooは安定度が高い Baz Bar Foo ・・・
37. なぜ依存の向きにこだわるのか 3. クリーンアーキテクチャって？ • Fooは安定度が高い • Barなどに変更が入ってもFooには 関係ない • FooはBarのことを知らない Baz Bar Foo ・・・ ❌ 変更
38. なぜ依存の向きにこだわるのか 3. クリーンアーキテクチャって？ • Fooは安定度が高い • Barなどに変更が入ってもFooには 関係ない • FooはBarのことを知らない • 依存されているものが多いほど安 定度は高いが... Baz Bar Foo ・・・
39. なぜ依存の向きにこだわるのか 3. クリーンアーキテクチャって？ • Fooは安定度が高い • Barなどに変更が入ってもFooには 関係ない • FooはBarのことを知らない • 依存されているものが多いほど安 定度は高いが... ◦ Fooに変更が入ったら依存されている ものに影響が出る ◦ なるべく変更されにくいものとしたい Baz Bar Foo ・・・ ❌ 影響 ❌ 変更 ❌ 影響 ❌ 影響
40. なぜ依存の向きにこだわるのか 3. クリーンアーキテクチャって？ • 依存しているほうの変更は影響を 与えない ◦ 影響を与えないということは変更しや すい Baz Bar Foo ・・・ ❌ 変更
41. ここまでをいったん整理 3. クリーンアーキテクチャって？ • 依存している ◦ 依存先の影響を受ける ▪ 安定度が低い ◦ 変更しても依存先に影響を与えない ▪ 変更しやすい • 依存されている ◦ 依存元の影響を受けない ▪ 安定度が高い ◦ 変更すると依存元に影響を与える ▪ なるべく変更したくない Bar Foo 依存している (依存元) 依存されている (依存先)
42. ここまでをいったん整理 3. クリーンアーキテクチャって？ • 依存している ◦ 依存先の影響を受ける ▪ 安定度が低い ◦ 変更しても依存先に影響を与えない ▪ 変更しやすい • 依存されている ◦ 依存元の影響を受けない ▪ 安定度が高い ◦ 変更すると依存元に影響を与える ▪ なるべく変更したくない Bar Foo 依存している (依存元) 依存されている (依存先) 詳細 (技術詳細) 方針 (ビジネスルール)
43. • 依存されている ◦ エンティティ、ユースケース • エンティティ(ドメインモデル) ◦ 企業のビジネスルール(方針) ▪ 変わらないもの ◦ 一番大事 • ユースケース ◦ エンティティを組み合わせてやりたい ことを達成する ◦ ビジネスを行う上でここも大事 • どれも下位の影響を受けたくない 実装例をもう一度見てみる 3. クリーンアーキテクチャって？
44. • 依存されている ◦ エンティティ、ユースケース • エンティティ(ドメインモデル) ◦ 企業のビジネスルール(方針) ▪ 変わらないもの ◦ 一番大事 • ユースケース ◦ エンティティを組み合わせてやりたい ことを達成する ◦ ビジネスを行う上でここも大事 • どれも下位の影響を受けたくない 実装例をもう一度見てみる 3. クリーンアーキテクチャって？
45. 2. 擬人化してみる 3. クリーンアーキテクチャって？ 実装例をもう一度見てみる ・ユースケースがフレー ムワークとドライバ(イン フラストラクチャ)に依存 していたら
46. 2. 擬人化してみる 3. クリーンアーキテクチャって？ 実装例をもう一度見てみる ・変わると困るもの、影 響を受けたくないものに 依存する ・ここはDBに限らない、 外部のAPIだったり、フ レームワークだったり
47. 2. 擬人化してみる 3. クリーンアーキテクチャって？ 実装例をもう一度見てみる ・ここに抽象(Interface) を用意 ・方針(重要なもの)を 詳細(些細なもの)に依存 させない ・詳細が抽象に依存する
48. 2. 擬人化してみる 3. クリーンアーキテクチャって？ 実装例をもう一度見てみる これをDIPという - 依存性逆転の原則 - Dependency Inversion Principle
49. 2. 擬人化してみる 3. クリーンアーキテクチャって？ 実装例をもう一度見てみる 依存性を注入することを DIという - 依存性の注入 - Dependency Injection
50. 2. 擬人化してみる 3. クリーンアーキテクチャって？ 実装例をもう一度見てみる ・UseCaseからの処理の 流れは変わらないけど、 下位への依存が無くなる ・DataAccessが上位の Interfaceに依存する(依 存先から依存元になる)
51. 2. 擬人化してみる 3. クリーンアーキテクチャって？ 実装例をもう一度見てみる ・UseCaseからすると DataAccessが何をして いるのかは知らなくて良 い ・技術詳細に無関心でい られる
52. DIPについてもう少し 3. クリーンアーキテクチャって？ • BarがBazを利用するとなった場合 • 循環依存になってしまう ◦ 依存先をたどると、自分に戻ってこれ る • 循環依存は避けたい Foo Bar Baz (変わりやす い)
53. DIPについてもう少し 3. クリーンアーキテクチャって？ • BarがBazを利用するとなった場合 • 循環依存になってしまう ◦ 依存先をたどると、自分に戻ってこれ る • 循環依存は避けたい ◦ 変更が入ったら伝播する ◦ もしかすると、Bazの変更がBarに伝 播してFooに伝播するかもしれない ❌ 変更 ❌ 影響 Foo Bar Baz (変わりやす い) ❌ 影響
54. DIPについてもう少し 3. クリーンアーキテクチャって？ • Barがやりたいことをインター フェイスとして用意 • Bazがインターフェイスのお約束 に沿って実装 • Barはインターフェイスに依存 • 循環依存しているものを有向非循 環グラフ(DAG)に戻す ◦ 依存先をたどっても、自分に戻らない 境界線 Foo Bar Baz (変わりやす い) XXX Interface
55. DIPについてもう少し 3. クリーンアーキテクチャって？ • Bazがインターフェイスの約束事 を守っている限り • Bazの変更はBarに伝播しない 境界線 Foo Bar Baz (変わりやす い) XXX Interface ❌ 変更
56. DIPについてもう少し 3. クリーンアーキテクチャって？ 境界線 Foo Bar Baz (変わりやす い) XXX Interface • 変わると困るもの、影響を受けた くないもの、変わりやすいものに 直接依存しないように依存関係を 逆転させる ◦ 抽象との会話にする ◦ インターフェイス超大事 • 依存の向きを整理する ◦ ぐちゃぐちゃした依存関係嫌ですよね • DIP超大事
57. けっきょく、クリーンアーキテクチャって？ 3. クリーンアーキテクチャって？ • 依存関係逆転の原則(DIP)をめちゃくちゃ大事にしている • 抽象を使って依存関係を逆転させる ◦ 方針(上位)に詳細(下位)の変更の影響を伝播させたくない • 方針(上位)を頑張って決めて、詳細(下位)の決定は後にする ◦ DIP使っていればできるよね • クリーンアーキテクチャを作っているのではない • エンティティ === ビジネス を作っている • 円の中心でビジネスを叫びたい • これを説明するために、あの同心円の図がただある • 詳細、抽象、方針の関係性が大事
58. けっきょく、クリーンアーキテクチャって？ 3. クリーンアーキテクチャって？ 誤解を恐れずに言うと
59. けっきょく、クリーンアーキテクチャって？ 3. クリーンアーキテクチャって？ クリーンアーキテクチャ なんてものはない
60. けっきょく、クリーンアーキテクチャって？ 3. クリーンアーキテクチャって？ クリーンな アーキテクチャへの みちしるべ
61. クリーンって？ 3. クリーンアーキテクチャって？ • 内部に異質なものがない • 依存がぐちゃぐちゃしていない • 変更に対する影響が予測可能
62. けっきょく、クリーンアーキテクチャって？ 3. クリーンアーキテクチャって？ そんなのむずくね？
63. けっきょく、クリーンアーキテクチャって？ 3. クリーンアーキテクチャって？ そこでSOLID原則がある
64. そんなのむずくね？ 3. クリーンアーキテクチャって？ • 依存がぐちゃぐちゃしていない • 変更に対する影響が予測可能 • この２つに関してはSOLID原則を適応していく ◦ 修正範囲を絞るために単一責任の原則(SRP)があるし • 閉鎖性共通の原則(CCP)のほうがしっくりくるかも ◦ 修正の影響を広げないためにオープン・クローズドの原則(OCP) があるし ◦ 余計なものに依存しないようにインターフェイス分離の原則 (ISP)がある • と思っている(DIPは言わずもがな、リスコフの置換原則(LSV)はすいません)
65. そんなのむずくね？ 3. クリーンアーキテクチャって？ • 内部に異質なものがない • 内部にはビジネスに対する問題領域を解決するためのピュアなオブ ジェクト(エンティティ)が求められる • どうやってエンティティを抽出するか • ガチでやるならモデリングが必要 • 詳細にどこまで依存して、どこから決別するのか検討する必要がある ◦ ActiveRecord • SOLID原則を使いながら依存を整理していく • 円の中心でエンティティを叫ばせる • アーキテクチャではなく、ビジネスを作る
66. けっきょく、クリーンアーキテクチャって？ 3. クリーンアーキテクチャって？ SOLID原則を突き詰めれば クリーンになる
67. けっきょく、クリーンアーキテクチャって？ 3. クリーンアーキテクチャって？ SOLID原則を突き詰めれば クリーンになる 失敗例から学ぶSOLID原則 - Speaker Deck https://speakerdeck.com/asumikam/failure-example-solid 神
68. けっきょく、クリーンアーキテクチャって？ 3. クリーンアーキテクチャって？ 依存の向きを整える
69. 1. クリーンアーキテクチャについて 2. 擬人化してみる 3. クリーンアーキテクチャって？ 4. まとめ 4. まとめ
70. 2. 擬人化してみる 4. まとめ 4. まとめ クリーンアーキテクチャは 擬人化するものじゃないし できるものでもなかった
71. • 4つのレイヤーはただの例 ◦ 中にも色々な役割/概念がある ◦ エンティティを作るための抽象化された考え方 ◦ わたしは無知だった • 大事なのは、詳細、抽象、方針 • クリーンアーキテクチャなんてものはない • あるのはクリーンなアーキテクチャへの道しるべ • SOLID原則を突き詰めるとクリーンになる • 依存の向きを整えて円の中心でエンティティを叫ばせる 2. 擬人化してみる 4. まとめ 4. まとめ
72. クリーンアーキテクチャと言えば？ 登場するのはこの4つのレイヤー (荒ぶってはいない) 4. まとめ
73. クリーンアーキテクチャと言えば？ この4つのレイヤーなんていらなかったんや ❌❌❌❌ 4. まとめ
74. 詳細くん、抽象ちゃん、方針さん だけでよかったんや クリーンアーキテクチャと言えば？ 4. まとめ
75. 詳細くん、抽象ちゃん、方針さん だけでよかったんや クリーンアーキテクチャと言えば？ 4. まとめ 距離が空いているな？
76. 詳細くん、抽象ちゃん、方針さん だけでよかったんや クリーンアーキテクチャと言えば？ 4. まとめ 外部からうるさく言ってくる人(詳細)から ビジネスを作りたい人(方針)を守る人(抽象) の図に見えなくもない(???)
77. 2. 擬人化してみる 4. まとめ 4. まとめ アーキテクチャではなく、 ビジネスを作る
78. 2. 擬人化してみる 4. まとめ 4. まとめ あなたは 何を作っていますか NO ENTITY, NO LIFE.
79. 2. 擬人化してみる 4. まとめ 4. まとめ 擬人化では 完全に理解できなかった クリーンアーキテクチャ
80. 2. 擬人化してみる 4. まとめ 4. まとめ 参考 • Clean Architecture 達人に学ぶソフトウェアの構造と設計 ◦ https://www.amazon.co.jp/dp/B07FSBHS2V • ちょうぜつソフトウェア設計入門 ◦ https://www.amazon.co.jp/dp/B0BNH1J2W2 • Software Design (ソフトウェアデザイン) 2023年6月号 ◦ https://www.amazon.co.jp/dp/B0C4K9X2XV ◦ クリーンアーキテクチャとは何か？ • 世界一わかりやすいClean Architecture - nuits.jp blog ◦ https://www.nuits.jp/entry/easiest-clean-architecture-2019-09 • Javaでクリーンアーキテクチャする方法 ◦ https://logmi.jp/tech/articles/323233
81. 2. 擬人化してみる 4. まとめ 4. まとめ ご清聴ありがとうございました