Grokking Simplicity探訪

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Grokking
Simplicity探訪
kawasima
アーキ部

Grokking Simplicity
2021年5月発売
日本語未訳
他Grokkingシリーズは「なっとく！」シリーズと
して続々翻訳されているが…

Data, Action, Calculation
計算
アクション
データ
実行結果が、何回実行するか、いつ実行するかに依存する
入力から出力を計算する
イベントに関する事実
例) メールを送る、データベースから読み込む
例) 最大値を探す、...

Calcuration
『Grokking Simplicity』の定義
入力から出力を計算する関数
● 外の世界に影響を与えず、外の世界の影響も受けない
● 例
○ +, *, -, /
○ Math.abs()
○ 文字列結合
○ Eメール...

Action
『Grokking Simplicity』の定義
外の世界に影響を与える、または外の世界の影響を受ける関数
したがって純関数でないもの、または副作用のあるもの
● 例:
○ Eメールを送信する
○ データベースから読み込む
○ フ...

Calculation 割合を増やしたい
Calculations Calculations
Actions Actions
こっちの方が安全でデバッグしやすい

https://speakerdeck.com/masuda220/big-ball-of-mud
このあたりの話は、増田さんのスライドでも書かれているので、
ぜひご覧になってください。

Action 波及ルール
Eric Normand『Stratified design and functional architecture』より
←これがActionだと…

Action 波及ルール
Eric Normand『Stratified design and functional architecture』より
←呼んでいる関数全体が
Actionになり…

Action 波及ルール
Eric Normand『Stratified design and functional architecture』より
←結果全てのコードがAction
になる

Action 波及ルールへ抵抗
できる限りコールツリーのリーフにCalculationを持ってくる必要がある
←Actionを呼んでいるので
これもActionになってしまう！

Layered Architectureでどうか?
Web層
Application層
Domain層
Data Access層
リーフがData AccessかDomainかになる
Data AccessはActionなので、
Calcul...

そこまでして純粋性にこだわる必要あるか?
https://www.slideshare.net/slideshow/ss-255489610/255489610
ないかもしれない。何を取りに行きたいのか? 要はバラ(略

終
と、これだけだとよくある話なのですが、
Calculation抽出を追う過程でより深い示唆がえられる
というのが今日の話です。

Grokking Simplicity
Deep Dive

Calculationを増すのを追い求めるのは、関数の呼び出し階層を作る行為でもある

階層？
Web層
Application層
Domain層
Data Access層
すでにレイヤ分けはしているのだが…?
何のためにレイヤを分けているのか?

そもそもレイヤードアーキテクチャと ?
● ソースコードの変更がシステム全体に波及しないようにする。変更は一つのコンポーネント
に閉じ込め、他の部分に影響を与えないようにする。
● インターフェースは安定しているべきである。
● システムの一部...

POSA Layered Architecture
Layer N
Layer N-1
Layer N-1
抽象度が高い
抽象度が低い
『Pattern-Oriented Software Architecture』
同じ抽象度のコンポーネント...

Traditional Layered Architecture レイヤ分割基準 ?
抽象度によって分かれている?
そもそも抽象とは何か?
Web層
Application層
Domain層
Data Access層

A, B, Cの共通項
A B C
全体
部分部分部分
これも含まれることがある
目的
手段手段手段
振る舞いにフォーカスすると…
抽象
抽象
抽象

目的-手段関係フラクタル
目的A
手段手段手段
手段
目的Aの手段
かつ目的B
目的Bの手段目的Bの手段手段
手段
目的Bの手段

Action, Calculation コールツリーも
目的-手段フラクタルで構成されれ …
目的
手段目的
手段目的
手段
抽象のレイヤーができる

Stratified Design
https://medium.com/clean-code-development/stratified-design-over-layered-design-125727c7e15
さらに、コールツリーを詳...

Composed Method
メソッドを他のメソッドの呼び出しから構成し、それぞれがほぼ同じ抽象度の
レベルにあるようにする。
※ ただしあまり具体的なことは『実装パターン』には書いてはいない
ケントベックならそうする

Stratified Designによってもたらされるも
Layered Architectureの本来の目的の1つ
● 似た責務を持つ要素をグループ化して理解しやすさと保守性を高めるべき

例題
ナントカPayを作ります。
● ウォレットにコインをチャージして、利用したり送金したりできます。
● 銀行口座を登録しておくと、そこからウォレットにチャージできます。これ
は必須ではありません。
● 銀行口座を登録する場合は、本人確認が必...

StratifiedでないDesgin
ユーザを登録する
運転免許証を使っ
た本人確認
銀行口座実在
確認
マイナンバーを
使った本人確認
csvから1行読
み出す
Eメールが他
ユーザと一致して
いないか
ユーザをDBに
保存する
初回登録...

StratifiedなDesign
ユーザを登録する
運転免許証を
使った本人確認
銀行口座実在
確認
マイナンバーを
使った本人確認
csvから1行読
み出す
ユーザをDBに保
存する
初回登録
リワード
本人確認する
銀行口座妥当
性を...

保守性↑
ユーザを登録する
運転免許証を
使った本人確認
マイナンバーを
使った本人確認
本人確認する
ユーザを登録する
運転免許証を
使った本人確認
マイナンバーを
使った本人確認
本人確認する
年金手帳を使っ
た本人確認
← 変更なし
本人...

理解しやすさ↑
Stratified
Non-Stratified

汎化
抽象化することを汎化(Generalization)するということもあるようだが…
抽象化すると汎用的になる、コードの再利用性を高めるってこと?

「汎用」 2つ意味がある
広範に使われる
広範を扱える
異なる概念
なので前ページのGPT-4oの回答には異を唱えたい

「広範を扱える」
上位は下位の目的になってお
り、下位は上位の手段になっ
ている。
目的
手段
抽象
具象
汎化
特化
柔軟性や理解容易性に関わってくる
いわゆる抽象化の概念

「広範に使われる」
ある手段が複数の目的で使われる。
再利用性に関わってくる

「汎用的なものを作ろう！」と言った場合、
どちらを指しているかを認識することが重要

「広範を扱え」で「広範に使われる」構造
「広範を扱える」と「広範に使われる」が両立するセミラティス構造
それらは両立可能で、両立するとこのような構造になるはず。
←リーフがCalculationになっている
とモアベター
←同じ抽象レベルのコン...

Bad Scenario
1. レイヤごとにコンポーネントを分割し、その責務を考える。
2. 柔軟性を持たせるために汎化できるものを考える (部分的抽象化)
3. 汎化した処理は、よりバリエーションの多いデータを受け付ける。
そのため処理に重複...

Stratified Design 階層特徴
目的
手段
抽象
具象
特定用途
汎用

Clean Architecture
“ソースコードの依存関係は常に内側を指す。内側に進むに
つれて、抽象度と方針のレベルが高まる。最も外側の円は
低レベルの具体的な詳細で構成されている。内側に進むに
つれて、ソフトウェアはより抽象的になり、高...

円中心ほど抽象度が高い?
円中心ほど抽象度が高いと言って
いるが、これが決定的な誤り。
ユースケースが目的で、ビジネス
ルールそ手段なで、ユース
ケース方がハイレベル、抽象度が
高い、と考えるが普通で ?

Controller
Repository
UseCase
Presenter
Business
Rules
Repository
Business
Rules
Repository
Impl
Presenter
Impl
もしかしたらDIPに...

そもそも実装分離ためインタフェース抽象と言えるだろうか?
Repository
RepositoryImpl

抽象化と …?
“抽象化とは物事を曖昧にすることではなく、むしろ
人が絶対的な正確さを発揮できる新しい意味の段階を
つくりだすこと”
Edsger W. Dijkstra

実装を切り離す目的インタフェースを抽象化と呼ない方が良いかも
Repository
RepositoryImpl
目的と手段の関係にはなっていないし、
新しい意味の段階を作ってはいない
Client
使う側はどちらにインタフェースと実装とど...

クリーンアーキテクチャ DIP 新しい意味段階を生み出しているわけでないで取り除いてみると…
Controller
Repository
UseCase
Presenter
Business
Rules
伝統的なレイヤードアーキテクチャと...

業務ルール抽象化
同じ振る舞いをグルーピングするだけで
なく、大まかに言えば同じ振る舞いと見
なせる新しい意味の段階を意図的に作る
ユーザを登録する
運転免許証を
使った本人確認
銀行口座実在
確認
マイナンバーを
使った本人確認
csvか...

業務ルール抽象化
● 業務ルールを抽象化しておくと、ルールの追加・変更が下位層に閉じ
柔軟性が増す。一度に脳にロードしておくべきコンポーネントが減
る、認知負荷が減るので、理解容易性が増す。
→ 「広範を扱える」ようにするメリット
● 業務ル...

で Stratified Design当たり前ことようなに、なぜメジャーじゃないか…?
https://ja.wikipedia.org/wiki/凝集度
抽象概念設計が難しく、ミスると凝集度を下げてしまうため

誤って凝集度を下げることなく、Stratified
なDesignをするやり方については、
7/13 の大吉祥寺.pmでお話する予定です！
お楽しみに！

Share Slideshare

LinkedIn
Facebook
Twitter

Embed

Size (px)

Show related Slideshows at end

WordPress Shortcode

Link

Share
Email

2024 Trend Updates: What Really Wor... by Search Engine Jou... 1036216 views
Storytelling For The Web: Integrate... by Chiara Aliotta 948112 views
Artificial Intelligence, Data and C... by OECD Directorate ... 870219 views
How to Leverage AI to Boost Employe... by SocialHRCamp 365506 views
2024 State of Marketing Report – by... by Marius Sescu 207694 views
Everything You Need To Know About C... by Expeed Software 227895 views

View on Slideshare

1 of 50 Ad

View on Slideshare

1 of 50 Ad