Download as PDF, PPTX
Uploaded byYoshitaka Kawashima
Grokking Simplicity探訪
2024/6/5のアーキ部で話したスライドです。 Stratified Designの目的を中心に、そのメリットを考えてみます。
![[Dl輪読会]dl hacks輪読](https://cdn.slidesharecdn.com/ss_thumbnails/dldlhacks-161125051944-thumbnail.jpg?width=640&height=640&fit=bounds)
Grokking Simplicity探訪
- 1.
- 2.
- 3. Data, Action, Calculation 計算 アクション データ 実行結果が、何回実行するか、いつ実行するかに依存する 入力から出力を計算する イベントに関する事実 例)メールを送る、データベースから読み込む 例) 最大値を探す、メールアドレスの妥当性を検証する 例) 最大値を探す、メールアドレスの妥当性を検証する プログラムを以下の3つに分類してみよう
- 4. Calcuration 『Grokking Simplicity』の定義 入力から出力を計算する関数 ● 外の世界に影響を与えず、外の世界の影響も受けない ●例 ○ +, *, -, / ○ Math.abs() ○ 文字列結合 ○ Eメールアドレスのバリデーション
- 5. Action 『Grokking Simplicity』の定義 外の世界に影響を与える、または外の世界の影響を受ける関数 したがって純関数でないもの、または副作用のあるもの ● 例: ○Eメールを送信する ○ データベースから読み込む ○ ファイルに書き込む ● Actionは本番環境で安全に実行するのが難しい ● Actionはデバッグするのが難しい
- 6. Calculation 割合を増やしたい Calculations Calculations ActionsActions こっちの方が安全でデバッグしやすい
- 7.
- 8. Action 波及ルール Eric Normand『Stratifieddesign and functional architecture』より ←これがActionだと…
- 9. Action 波及ルール Eric Normand『Stratifieddesign and functional architecture』より ←呼んでいる関数全体が Actionになり…
- 10. Action 波及ルール Eric Normand『Stratifieddesign and functional architecture』より ←結果全てのコードがAction になる
- 11.
- 12. Layered Architectureで どうか? Web層 Application層 Domain層 DataAccess層 リーフがData AccessかDomainかになる Data AccessはActionなので、 CalculationなDomainを作らない限り、 全てがActionになってしまう。 Traditional Layered Architecture
- 13.
- 14.
- 15.
- 16.
- 17.
- 18. そもそもレイヤードアーキテクチャと ? ● ソースコードの変更がシステム全体に波及しないようにする。変更は一つのコンポーネント に閉じ込め、他の部分に影響を与えないようにする。 ●インターフェースは安定しているべきである。 ● システムの一部は交換可能であるべきである。コンポーネントは、システムの他の部分に影 響を与えることなく、代替実装に置き換えられるべきである。 ● 似た責務を持つ要素をグループ化して理解しやすさと保守性を高めるべきである。各コン ポーネントは一貫性を持つべきであり、一つのコンポーネントが異なる問題を実装すると、 その整合性が失われる可能性がある。グループ化と一貫性は時に対立する。 『Pattern-Oriented Software Architecture』
- 19. POSA Layered Architecture LayerN Layer N-1 Layer N-1 抽象度が高い 抽象度が低い 『Pattern-Oriented Software Architecture』 同じ抽象度のコンポーネントをグルーピングする 各レイヤのコンポーネントは、自分と同じか1つ 下のレイヤの機能のみに依存する。 個々のレイヤー内ではすべてのコンポーネントが 同じ抽象レベルで動作することが不可欠。
- 20. Traditional Layered Architectureレイヤ分割基準 ? 抽象度によって分かれている? そもそも抽象とは何か? Web層 Application層 Domain層 Data Access層
- 21. A, B, Cの共通項 AB C 全体 部分 部分 部分 これも含まれることがある 目的 手段 手段 手段 振る舞いにフォーカスすると… 抽象 抽象 抽象
- 22. 目的-手段 関係 フラクタル 目的A 手段手段 手段 手段 目的Aの手段 かつ目的B 目的Bの手段 目的Bの手段 手段 手段 目的Bの手段
- 23. Action, Calculation コールツリーも 目的-手段フラクタルで構成されれ … 目的 手段 目的 手段 目的 手段 抽象のレイヤーができる
- 24.
- 25.
- 26. Stratified Designによってもたらされるも Layered Architectureの本来の目的の1つ ●似た責務を持つ要素をグループ化して理解しやすさと保守性を高めるべき
- 27. 例題 ナントカPayを作ります。 ● ウォレットにコインをチャージして、利用したり送金したりできます。 ● 銀行口座を登録しておくと、そこからウォレットにチャージできます。これ は必須ではありません。 ●銀行口座を登録する場合は、本人確認が必要です。本人確認は免許証または マイナンバーで行います(外部API利用) ● 口座番号が実在するか確認する必要があります。(外部API利用) ● メールアドレスがブラックリストに載っていれば登録できません。(ブラック リストはテキストファイルに1行ずつNGメールアドレスが記載されている) ● メールアドレスは全ユーザで一意でなくてはなりません。 ● これまで一度も登録したことのないユーザであれば、ウォレットに500コイン を付与します。 https://bitbucket.org/kawasima/design-kata/src/main/src/example/06_pay/
- 28.
- 29. StratifiedなDesign ユーザを登録する 運転免許証を 使った本人確認 銀行口座 実在 確認 マイナンバーを 使った本人確認 csvから1行読 み出す ユーザをDBに保 存する 初回登録 リワード 本人確認する 銀行口座 妥当 性を確認する メールアドレス妥 当性チェック Eメールが他 ユーザと一致し ていないか Eメールによる ユーザ検索 ブラックリストにメ アドが載っていな い 初回登録か判定 初回登録検索 初回登録コイン 付与 ←大まかな業務ルール ↓詳細の業務ルール https://bitbucket.org/kawasima/design-kata/src/main/src/example/06_pay/register.ts
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38. Bad Scenario 1. レイヤごとにコンポーネントを分割し、その責務を考える。 2.柔軟性を持たせるために汎化できるものを考える (部分的抽象化) 3. 汎化した処理は、よりバリエーションの多いデータを受け付ける。 そのため処理に重複するところが出てくる。 4. 重複するところを共通関数(下請けメソッド)として切り出す。(部分的再利用性) レイヤごとに責務を割り当てる設計からスタート する術しか持っていない場合… よく見かけるヤツ！
- 39. Stratified Design 階層特徴 目的 手段 抽象 具象 特定用途 汎用
- 40.
- 41. 円 中心ほど抽象度が高い? 円 中心ほど抽象度が高いと言って いるが、これが決定的な誤り。 ユースケースが目的で、ビジネス ルールそ 手段な で、ユース ケース 方がハイレベル、抽象度が 高い、と考える が普通で ?
- 42. Controller Repository UseCase Presenter Business Rules Repository Business Rules Repository Impl Presenter Impl もしかしたらDIPによる依存 逆転が ある で、最下層が一番抽象的と 言っているかもしれない … …が、Business Rules UseCase 手 段であり、ここに関して POSA レ イヤリング 定義にピタッと当て ま る で、UseCase 方が抽象度が高 いだろう…
- 43. そもそも実装分離 ため インタフェース抽象と言える だろうか? Repository RepositoryImpl
- 44.
- 45.
- 46. クリーンアーキテクチャ DIP 新しい意味段階を生み出しているわけで ない で取り除いてみると… Controller Repository UseCase Presenter Business Rules 伝統的なレイヤードアーキテクチャと なんら変わらない。 Repository Business Rules ← 大事なのはこのレイヤのStratified Design
- 47. 業務ルール 抽象化 同じ振る舞いをグルーピングするだけで なく、大まかに言えば同じ振る舞いと見 なせる新しい意味の段階を意図的に作る ユーザを登録する 運転免許証を 使った本人確認 銀行口座 実在 確認 マイナンバーを 使った本人確認 csvから1行読 み出す ユーザをDBに保 存する 初回登録 リワード 本人確認する 銀行口座妥当 性を確認する メールアドレス 妥 当性チェック Eメールが他 ユーザと一致し ていないか Eメールによる ユーザ検索 ブラックリストにメ アドが載っていな い 初回登録か判定 初回登録検索 初回登録コイン 付与 ←大まかな業務ルール ↓詳細の業務ルール
- 48. 業務ルール 抽象化 ● 業務ルールを抽象化しておくと、ルールの追加・変更が下位層に閉じ 柔軟性が増す。一度に脳にロードしておくべきコンポーネントが減 る、認知負荷が減るので、理解容易性が増す。 →「広範を扱える」ようにするメリット ● 業務ルールを抽象化しておくと、下位層のルールの再利用性が増す。 → 「広範に使える」ようにするメリット ○ ルール自体をコピペするのではなく、詳細ルールを合成して、 新しいルールを作ることもできる。
- 49. で Stratified Design当たり前こと ような に、なぜメジャーじゃない か…? https://ja.wikipedia.org/wiki/凝集度 抽象概念 設計が難しく、ミスると凝集度を下げてしまうため
- 50.