Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
クリーンアーキテクチャ輪読会資料 12-14章
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
koji
February 10, 2020
Technology
0
34
クリーンアーキテクチャ輪読会資料 12-14章
参加しているコミュニティ、Challeng-Every-Monthの輪読会で作成した資料。
koji
February 10, 2020
Tweet
Share
More Decks by koji
See All by koji
20250914_Vibe Coding初学者向け勉強会_Devinについて
kjman678
0
31
Amazon Builder's Library 輪読会資料 ジッターを伴うタイムアウト、再試行、およびバックオフ
kjman678
0
76
時系列解析 輪読会資料 1章
kjman678
0
36
クリーンアーキテクチャ輪読会資料 27-29章
kjman678
0
44
Amazon Builder's Library 輪読会資料 分散システムでのフォールバックの回避
kjman678
0
65
Amazon Builder's Library 輪読会資料 負荷制限を使用して過負荷を回避する
kjman678
0
39
Other Decks in Technology
See All in Technology
旅先で iPad + Neovim で iOS 開発・執筆した話
zozotech
PRO
0
100
pool.ntp.orgに ⾃宅サーバーで 参加してみたら...
tanyorg
0
1.4k
AIが実装する時代、人間は仕様と検証を設計する
gotalab555
1
600
Red Hat OpenStack Services on OpenShift
tamemiya
0
140
Context Engineeringが企業で不可欠になる理由
hirosatogamo
PRO
3
680
AIエージェントを開発しよう!-AgentCore活用の勘所-
yukiogawa
0
190
こんなところでも(地味に)活躍するImage Modeさんを知ってるかい?- Image Mode for OpenShift -
tsukaman
1
170
Context Engineeringの取り組み
nutslove
0
380
プロポーザルに込める段取り八分
shoheimitani
1
670
今こそ学びたいKubernetesネットワーク ~CNIが繋ぐNWとプラットフォームの「フラッと」な対話
logica0419
5
520
Agent Skils
dip_tech
PRO
0
140
Greatest Disaster Hits in Web Performance
guaca
0
300
Featured
See All Featured
Bootstrapping a Software Product
garrettdimon
PRO
307
120k
The Invisible Side of Design
smashingmag
302
51k
[RailsConf 2023] Rails as a piece of cake
palkan
59
6.3k
Lightning talk: Run Django tests with GitHub Actions
sabderemane
0
120
Context Engineering - Making Every Token Count
addyosmani
9
670
Public Speaking Without Barfing On Your Shoes - THAT 2023
reverentgeek
1
310
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
231
22k
Have SEOs Ruined the Internet? - User Awareness of SEO in 2025
akashhashmi
0
270
How to optimise 3,500 product descriptions for ecommerce in one day using ChatGPT
katarinadahlin
PRO
0
3.4k
Designing for Performance
lara
610
70k
How to Build an AI Search Optimization Roadmap - Criteria and Steps to Take #SEOIRL
aleyda
1
1.9k
SEO Brein meetup: CTRL+C is not how to scale international SEO
lindahogenes
0
2.4k
Transcript
クリーンアーキテクチャ輪読会 12-14章 2020/02/10(月)22:00- 発表者 koji/メガネ男 1
• コンポーネントとはデプロイの単位をあらわす 例)Javaならjarファイル、Rubyならgemファイル、.NETならDLL • よくできたコンポーネントは常に個別にデプロイできる状態を保っており、 個別に開発を進めることが可能。 • プログラミングの歴史は、ソフトウェア/ハードの進化と、プログラムの巨大 化のいたちごっこである。 12章 》コンポーネント
2
どのクラスをどのコンポーネントに含めるかの判断基準 1. 再利用・リリース等価の原則(REP) 2. 閉鎖性共通の原則(CCP) 3. 全再利用の原則(CRP) 13章 》コンポーネントの凝集性 3
再利用・リリース等価の原則(REP) • リリースのバージョン=再利用できるコンポーネントの単位 →リリース番号を確認することで開発者は再利用するコンポーネントの互 換性を確認できるから。 • 一つのコンポーネントを形成するクラスやモジュールは、まとめてリリース 可能なものでなければならない。 13章 》コンポーネントの凝集性 4
閉鎖性共通の原則(CCP) • 同じタイミングで変更されるクラスは1つにまとめておくべき。 全再利用の原則(CRP) • 一緒に用いられないクラスやモジュールは、同じコンポーネントにまとめて おくべきではない。 →でないと、再デプロイに手間がかかってしまう。 13章 》コンポーネントの凝集性 5
• 凝集性に関するこれらの原則には相反するところがある。 • 再利用・リリース等価の原則(REP)と閉鎖性共通の原則(CCP)は、包含 関係にある。 • 全再利用の原則(CRP)は、これらとは相反する原則。 • これら3つの原則のバランスを •
うまくとるのが、アーキテクトの • 腕の見せどころ。 13章 》コンポーネントの凝集性 6
コンポーネントの関連性を取り扱う原則 1. 非循環依存関係の原則(ADP) 2. 安定依存の原則(SDP) 3. 安定度・抽象度等価の原則(SAP) 14章 》コンポーネントの結合 7
非循環依存関係の原則(ADP) • 「二日酔い症候群」 昨日の夜動いたプログラムが翌朝動かなくなっていること。 大勢の開発者が同じソースコードを変更する開発現場で発症する。 対策 1. 週次ビルド 2. 非循環依存関係の原則
14章 》コンポーネントの結合 8
週次ビルド • 各メンバーの作業の統合を間隔をあけて行うこと 間隔を開ければ開けるほど、統合まではスムーズに作業できるが、統合作 業が大変になるし、フィードバックも遅れる。 この問題点は、開発環境をリリース可能なコンポーネントに分割すれば解 決。 • ただし、コンポーネントの依存関係をきちんと管理する必要あり。 相互依存が合ってはいけない。
14章 》コンポーネントの結合 9
• どのような状況でもコンポートの相互依存を排除することが可能 • 依存関係逆転の原則を適用する。 Userが依存するインターフェースをつくり、インターフェースの場所を移動さ せる。 14章 》コンポーネントの結合 10 変更前 変更後
• EntitiesとAuthorizerの両方が依存するコンポーネントを作って、両方のコ ンポーネントが依存するクラスをこのコンポーネントに移動させる。 14章 》コンポーネントの結合 11
• システム設計後もコンポーネントの構造は変化するため、トップダウン設計 は不可能。 • 最優先に対処すべきは、頻繁に変更されるコンポーネントが安定すべきコ ンポーネントに影響をおよぼすこと(変動性の分離)。 14章 》コンポーネントの結合 12
安定依存の原則(SDP) • 安定度の高い方向に依存すること。 安定度の指標 依存していると不安、依存されていると安定 • ファン・イン(依存入力数)コンポーネント内のクラスに依存している外部の コンポーネントの数 (イメージ:イン=頼られる) • ファン・アウト(依存出力数)外部のコンポーネントに依存しているクラスの
数 (イメージ:アウト=依存する) • I = インスタビリティ(不安定さ) ファンアウト÷(ファンイン+ファンアウト) 14章 》コンポーネントの結合 13
(ややこしいので事例) • コンポーネントCcは、Ccの外部に あるq、r、sに依存されている。 ファンイン=3 • Ccの内部にあるクラスは、Ccの 外部vに依存している ファンアウト=1 •
インスタビリティ= 1/(3 + 1) = 1/4 14章 》コンポーネントの結合 14
• ただし、すべてのコンポーネントが最大に安定していると、そのシステムに は手を加えることができず、その状況は望むところではない。 • 理想的な構成は、安定度の高いコンポーネントもあれば、安定度の低いコ ンポーネントもある状態。 14章 》コンポーネントの結合 15
• 安定度依存の原則に違反している例 • 安定度の高いコンポーネントFlexibleに、Stableを依存させてしまってい る。 Stablのインスタビリティは、 Flexibleよりずっと小さく、 Flexibleは変更しづらいものに なってしまうから。 •
これを解決するには、Stable からFlexibleへの依存度を取り 除く必要がある。 14章 》コンポーネントの結合 16
依存関係逆転の原則(DIP)適用のイメージ図 • インターフェイスのUSをつくり、これをコンポーネントUServerに格納する。 Cにこのインターフェースを実装すると、StableがFlexbleに依存することは なくなり、両方のコンポーネントがUserverに依存するようになる。 14章 》コンポーネントの結合 17
安定度・抽象度等価の原則(SAP) • コンポーネントの抽象度は、その安定度と同程度でなければいけない。 安定度 高い 低い 配置すべき 上位レベルの方針 素早く変更するソフト • 上位レベルの方針を安定度の高いコンポーネントに配置すると、ソース コードを変更しづらくなり、柔軟性を失う。 • 安定度の高いコンポーネントを変更せず済ませるためには、抽象クラスを
使うとよい。 14章 》コンポーネントの結合 18
• コンポーネントの安定度を高くするためには、柔軟性を持たせるため拡張 可能なインターフェースと抽象クラスで構成すべき。 • 安定度が高い方に依存すべきであり、安定度と抽象度は連動する →抽象度が高くなるほうに依存すべき。 14章 》コンポーネントの結合 19
抽象度の計測 • コンポーネントの抽象度Aは、抽象クラスが占める割合 (コンポーネント内の抽象クラス・インターフェイスの総数)÷コンポーネント 内のクラスの総数 主系列 • 安定度(I) と 抽象度(A) の関係 コンポーネントがプロットされるべきでない範囲、すなわち苦痛ゾーン、無 駄ゾーンを見つけるとよい。
14章 》コンポーネントの結合 20
苦痛ゾーン、無駄ゾーン • (0,0)の近辺のコンポーネントは、安定しすぎて 柔軟性を欠き、抽象度も低く拡張できない。 苦痛ゾーンと呼ばれ、ここは除外すべき。 • (1,1)の近辺のコンポーネントは、抽象度が高いにもかかわらず、 それに依存するコンポーネントがない。 使われていないコードや、実装が一つもないまま放置された抽象クラスな どで、無駄ゾーンと呼ばれる無意味なコンポーネントである。
14章 》コンポーネントの結合 21
• 除外すべきゾーンを回避する • 無駄ゾーンと苦痛ゾーンから最も遠く 離れた点を結ぶ軌跡、(1,0)、(0,1)をつなぐ 直線を主系列と呼ぶ。 • インスタビリティ、抽象度のバランスが良く、依存もされていたり、していた り。 •
コンポーネントにとって理想的なのは、主系列の両端どちらかである。 14章 》コンポーネントの結合 22
主系列からの距離 • 主系列(理想)からどの程度離れているか 距離(D)=|抽象度(A)+安定度(I)-1| • 共分散を算定して統計的に設計することも可能。 • 記録を取って異常の検知に使用することもできる。 14章 》コンポーネントの結合 23
主系列からの距離 • 主系列(理想)からどの程度離れているか 距離(D)=|抽象度(A)+安定度(I)-1 | • 共分散を算定して統計的に設計することも可能。 • 記録を取って異常の検知に使用することもできる。 14章 》コンポーネントの結合
24
• 依存性逆転の原則の話題に関連して クリーンアーキテクチャにおける「安定」に関する理解に役立ちそう。 ボブおじさんは倒錯的な表現を好む、SQLは安定している等。 • Clean Architectureを読んだ感想 「抽象化」に関する理解に役立ちそう。 抽象化にはコストが伴う、設計なんて考えずに、動けばいいやで書いたほ うがサクッと作れるが機能変更、追加時に高くつく、抽象化は将来への投
資。 参考 25