Download as PDF, PPTX
Uploaded byYoshitaka Kawashima
PDF, PPTX3,058 views
Grokking Simplicity探訪
2024/6/5のアーキ部で話したスライドです。Stratified Designの目的を中心に、そのメリットを考えてみます。
Recommended
More Related Content
What's hot
More from Yoshitaka Kawashima
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 CalculationsActionsActionsこっちの方が安全でデバッグしやすい
- 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 ArchitectureLayerNLayer N-1Layer 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 Scenario1. レイヤごとにコンポーネントを分割し、その責務を考える。2.柔軟性を持たせるために汎化できるものを考える (部分的抽象化)3. 汎化した処理は、よりバリエーションの多いデータを受け付ける。そのため処理に重複するところが出てくる。4. 重複するところを共通関数(下請けメソッド)として切り出す。(部分的再利用性)レイヤごとに責務を割り当てる設計からスタートする術しか持っていない場合…よく見かけるヤツ！
- 39.Stratified Design 階層特徴目的手段抽象具象特定用途汎用
- 40.
- 41.円 中心ほど抽象度が高い?円 中心ほど抽象度が高いと言っているが、これが決定的な誤り。ユースケースが目的で、ビジネスルールそ 手段な で、ユースケース 方がハイレベル、抽象度が高い、と考える が普通で ?
- 42.ControllerRepositoryUseCasePresenterBusinessRulesRepositoryBusinessRulesRepositoryImplPresenterImplもしかしたらDIPによる依存 逆転がある で、最下層が一番抽象的と言っているかもしれない ……が、Business Rules UseCase 手段であり、ここに関して POSA レイヤリング 定義にピタッと当て まる で、UseCase 方が抽象度が高いだろう…
- 43.そもそも実装分離 ため インタフェース抽象と言える だろうか?RepositoryRepositoryImpl
- 44.
- 45.
- 46.クリーンアーキテクチャ DIP 新しい意味段階を生み出しているわけで ない で取り除いてみると…ControllerRepositoryUseCasePresenterBusinessRules伝統的なレイヤードアーキテクチャとなんら変わらない。RepositoryBusinessRules← 大事なのはこのレイヤのStratified Design
- 47.業務ルール 抽象化同じ振る舞いをグルーピングするだけでなく、大まかに言えば同じ振る舞いと見なせる新しい意味の段階を意図的に作るユーザを登録する運転免許証を使った本人確認銀行口座 実在確認マイナンバーを使った本人確認csvから1行読み出すユーザをDBに保存する初回登録リワード本人確認する銀行口座妥当性を確認するメールアドレス 妥当性チェックEメールが他ユーザと一致していないかEメールによるユーザ検索ブラックリストにメアドが載っていない初回登録か判定初回登録検索初回登録コイン付与←大まかな業務ルール↓詳細の業務ルール
- 48.業務ルール 抽象化● 業務ルールを抽象化しておくと、ルールの追加・変更が下位層に閉じ柔軟性が増す。一度に脳にロードしておくべきコンポーネントが減る、認知負荷が減るので、理解容易性が増す。→「広範を扱える」ようにするメリット● 業務ルールを抽象化しておくと、下位層のルールの再利用性が増す。→ 「広範に使える」ようにするメリット○ ルール自体をコピペするのではなく、詳細ルールを合成して、新しいルールを作ることもできる。
- 49.で Stratified Design当たり前こと ような に、なぜメジャーじゃない か…?https://ja.wikipedia.org/wiki/凝集度抽象概念 設計が難しく、ミスると凝集度を下げてしまうため
- 50.