クリーンアーキテクチャ輪読会資料 12-14章

参加しているコミュニティ、Challeng-Every-Monthの輪読会で作成した資料。

Transcript

1. クリーンアーキテクチャ輪読会 12-14章 2020/02/10(月)22:00- 発表者　koji/メガネ男 1
2. • コンポーネントとはデプロイの単位をあらわす 例）Javaならjarファイル、Rubyならgemファイル、.NETならDLL • よくできたコンポーネントは常に個別にデプロイできる状態を保っており、 個別に開発を進めることが可能。 • プログラミングの歴史は、ソフトウェア/ハードの進化と、プログラムの巨大 化のいたちごっこである。 12章　》コンポーネント 2
3. どのクラスをどのコンポーネントに含めるかの判断基準 1. 再利用・リリース等価の原則（REP） 2. 閉鎖性共通の原則（CCP） 3. 全再利用の原則（CRP） 13章　》コンポーネントの凝集性 3
4. 再利用・リリース等価の原則（REP） • リリースのバージョン＝再利用できるコンポーネントの単位 →リリース番号を確認することで開発者は再利用するコンポーネントの互 換性を確認できるから。 • 一つのコンポーネントを形成するクラスやモジュールは、まとめてリリース 可能なものでなければならない。 13章　》コンポーネントの凝集性 4
5. 閉鎖性共通の原則（CCP） • 同じタイミングで変更されるクラスは1つにまとめておくべき。 全再利用の原則（CRP） • 一緒に用いられないクラスやモジュールは、同じコンポーネントにまとめて おくべきではない。 →でないと、再デプロイに手間がかかってしまう。 13章　》コンポーネントの凝集性 5
6. • 凝集性に関するこれらの原則には相反するところがある。 • 再利用・リリース等価の原則（REP）と閉鎖性共通の原則（CCP）は、包含 関係にある。 • 全再利用の原則（CRP）は、これらとは相反する原則。 • これら3つの原則のバランスを • うまくとるのが、アーキテクトの • 腕の見せどころ。 13章　》コンポーネントの凝集性 6
7. コンポーネントの関連性を取り扱う原則 1. 非循環依存関係の原則（ADP） 2. 安定依存の原則（SDP） 3. 安定度・抽象度等価の原則（SAP） 14章　》コンポーネントの結合 7
8. 非循環依存関係の原則（ADP） • 「二日酔い症候群」 昨日の夜動いたプログラムが翌朝動かなくなっていること。 大勢の開発者が同じソースコードを変更する開発現場で発症する。 対策 1. 週次ビルド 2. 非循環依存関係の原則 14章　》コンポーネントの結合 8
9. 週次ビルド　 • 各メンバーの作業の統合を間隔をあけて行うこと 間隔を開ければ開けるほど、統合まではスムーズに作業できるが、統合作 業が大変になるし、フィードバックも遅れる。 この問題点は、開発環境をリリース可能なコンポーネントに分割すれば解 決。 • ただし、コンポーネントの依存関係をきちんと管理する必要あり。 相互依存が合ってはいけない。 14章　》コンポーネントの結合 9
10. • どのような状況でもコンポートの相互依存を排除することが可能 • 依存関係逆転の原則を適用する。 Userが依存するインターフェースをつくり、インターフェースの場所を移動さ せる。 14章　》コンポーネントの結合 10 変更前 変更後
11. • EntitiesとAuthorizerの両方が依存するコンポーネントを作って、両方のコ ンポーネントが依存するクラスをこのコンポーネントに移動させる。 14章　》コンポーネントの結合 11
12. • システム設計後もコンポーネントの構造は変化するため、トップダウン設計 は不可能。 • 最優先に対処すべきは、頻繁に変更されるコンポーネントが安定すべきコ ンポーネントに影響をおよぼすこと（変動性の分離）。 14章　》コンポーネントの結合 12
13. 安定依存の原則（SDP） • 安定度の高い方向に依存すること。 安定度の指標 　依存していると不安、依存されていると安定 • ファン・イン（依存入力数）コンポーネント内のクラスに依存している外部の コンポーネントの数　（イメージ：イン＝頼られる） • ファン・アウト（依存出力数）外部のコンポーネントに依存しているクラスの 数　（イメージ：アウト＝依存する） • I = インスタビリティ（不安定さ）　ファンアウト÷（ファンイン＋ファンアウト） 14章　》コンポーネントの結合 13
14. （ややこしいので事例） • コンポーネントCcは、Ccの外部に あるq、r、sに依存されている。 ファンイン=3 • Ccの内部にあるクラスは、Ccの 外部vに依存している ファンアウト=1 • インスタビリティ= 1/(3 + 1) = 1/4 14章　》コンポーネントの結合 14
15. • ただし、すべてのコンポーネントが最大に安定していると、そのシステムに は手を加えることができず、その状況は望むところではない。 • 理想的な構成は、安定度の高いコンポーネントもあれば、安定度の低いコ ンポーネントもある状態。 14章　》コンポーネントの結合 15
16. • 安定度依存の原則に違反している例 • 安定度の高いコンポーネントFlexibleに、Stableを依存させてしまってい る。 Stablのインスタビリティは、 Flexibleよりずっと小さく、 Flexibleは変更しづらいものに なってしまうから。 • これを解決するには、Stable からFlexibleへの依存度を取り 除く必要がある。 14章　》コンポーネントの結合 16
17. 依存関係逆転の原則（DIP）適用のイメージ図 • インターフェイスのUSをつくり、これをコンポーネントUServerに格納する。 Ｃにこのインターフェースを実装すると、StableがFlexbleに依存することは なくなり、両方のコンポーネントがUserverに依存するようになる。 14章　》コンポーネントの結合 17
18. 安定度・抽象度等価の原則（SAP） • コンポーネントの抽象度は、その安定度と同程度でなければいけない。 安定度　　　　　　高い　　　　　　　　　　　　　　　低い 配置すべき　上位レベルの方針　　　　　　　　素早く変更するソフト • 上位レベルの方針を安定度の高いコンポーネントに配置すると、ソース コードを変更しづらくなり、柔軟性を失う。 • 安定度の高いコンポーネントを変更せず済ませるためには、抽象クラスを 使うとよい。 14章　》コンポーネントの結合 18
19. • コンポーネントの安定度を高くするためには、柔軟性を持たせるため拡張 可能なインターフェースと抽象クラスで構成すべき。 • 安定度が高い方に依存すべきであり、安定度と抽象度は連動する →抽象度が高くなるほうに依存すべき。 14章　》コンポーネントの結合 19
20. 抽象度の計測 • コンポーネントの抽象度Aは、抽象クラスが占める割合 （コンポーネント内の抽象クラス・インターフェイスの総数）÷コンポーネント 内のクラスの総数 主系列 • 安定度(I)　と　抽象度(A)　の関係 コンポーネントがプロットされるべきでない範囲、すなわち苦痛ゾーン、無 駄ゾーンを見つけるとよい。 14章　》コンポーネントの結合 20
21. 苦痛ゾーン、無駄ゾーン • (0,0)の近辺のコンポーネントは、安定しすぎて 柔軟性を欠き、抽象度も低く拡張できない。 苦痛ゾーンと呼ばれ、ここは除外すべき。 • (1,1)の近辺のコンポーネントは、抽象度が高いにもかかわらず、 それに依存するコンポーネントがない。 使われていないコードや、実装が一つもないまま放置された抽象クラスな どで、無駄ゾーンと呼ばれる無意味なコンポーネントである。 14章　》コンポーネントの結合 21
22. • 除外すべきゾーンを回避する • 無駄ゾーンと苦痛ゾーンから最も遠く 離れた点を結ぶ軌跡、(1,0）、（0,1）をつなぐ 直線を主系列と呼ぶ。 • インスタビリティ、抽象度のバランスが良く、依存もされていたり、していた り。 • コンポーネントにとって理想的なのは、主系列の両端どちらかである。 14章　》コンポーネントの結合 22
23. 主系列からの距離 • 主系列（理想）からどの程度離れているか 距離(D)＝｜抽象度(A)＋安定度(I)-1| • 共分散を算定して統計的に設計することも可能。 • 記録を取って異常の検知に使用することもできる。 14章　》コンポーネントの結合 23
24. 主系列からの距離 • 主系列（理想）からどの程度離れているか 距離(D)＝｜抽象度(A)＋安定度(I)-1 | • 共分散を算定して統計的に設計することも可能。 • 記録を取って異常の検知に使用することもできる。 14章　》コンポーネントの結合 24
25. • 依存性逆転の原則の話題に関連して クリーンアーキテクチャにおける「安定」に関する理解に役立ちそう。 ボブおじさんは倒錯的な表現を好む、SQLは安定している等。　 • Clean Architectureを読んだ感想 「抽象化」に関する理解に役立ちそう。 抽象化にはコストが伴う、設計なんて考えずに、動けばいいやで書いたほ うがサクッと作れるが機能変更、追加時に高くつく、抽象化は将来への投 資。 参考 25