設計におけるソリューションドメイン

Transcript

1. 設計におけるソリューションドメイン 吉田あひる
2. 自己紹介 名前: 吉田あひる (@strtyuu) 所属: スターフェスティバル株式会社 仕事: バックエンドエンジニア 焼肉を奢らない人です Laravel.shibuya というイベントを共同運営しています。 はじめに 設計におけるソリューションドメイン
3. このセッションについて 設計というアクティビティにおけるソリューションドメインの重要性を改めて整理し て初心(?)にかえろうという試みです。 ※ 論理的なモデルに憧れすぎて技術を若干軽視した考え方になっていた頃の自分へ伝え たい内容となっております はじめに 設計におけるソリューションドメイン
4. ソリューションドメインとは ソリューションドメインとは 設計におけるソリューションドメイン
5. ソリューションドメインとは 設計におけるソリューションドメイン
6. ソリューションドメインとは 設計におけるソリューションドメイン
7. ソリューションドメインとは 設計におけるソリューションドメイン
8. 解決構造の導き方 解決構造の導き方 設計におけるソリューションドメイン
9. ここでいう解決構造とは 問題を解決するために構築されたモデルや実装のこと 解決構造の導き方 設計におけるソリューションドメイン
10. 共通性と可変性 共通性と可変性 設計におけるソリューションドメイン
11. 共通性 複数のモノやコトに共通する部分 データ構造 振る舞い アルゴリズム etc... 共通性と可変性 設計におけるソリューションドメイン
12. データ構造の共通性 EC サイトの商品であれば、全ての商品は 商品名 商品説明 価格 といったデータを持つなど 共通性と可変性 設計におけるソリューションドメイン
13. 振る舞いの共通性 例えば電話を考えたときに、黒電話であってもスマホであっても 着信があればそれを知らせる 通話のためのコネクションを確立する という共通する振る舞いをもつなど 共通性と可変性 設計におけるソリューションドメイン
14. アルゴリズムの共通性 クイックソートであれば 1.基準値を決める 2.基準値より大きいグループと小さいグループに分ける 3.分けたグループに対して同じことを繰り返す という、並び替える対象に影響されない手順自体の共通性など 共通性と可変性 設計におけるソリューションドメイン
15. 可変性 共通性という枠組みの中で可変する部分 データ構造が共通していても値(状態)は可変 振る舞いは共通していても実装は可変 など 共通性と可変性 設計におけるソリューションドメイン
16. ソリューションドメインにおける共通性と可変性 ソリューションドメインにおける共通性と可変性 設計におけるソリューションドメイン
17. 共通性と可変性を扱える解決手段 プログラミング言語 一部のデザインパターン ライブラリ(今回は取り上げません) ソリューションドメインにおける共通性と可変性 設計におけるソリューションドメイン
18. PHP が表現できる共通性・可変性 (一部) 共通性 可変性 機能 振る舞い・データ構造 状態 Class 名前(意味) or 振る舞い 振る舞い or 実装 Interface 振る舞い 型 Trait データ構造 小さい値の組 Enum ※ 実際には共通性・可変性の他にバインディング時期など他にも考慮するポイントがあ る ソリューションドメインにおける共通性と可変性 設計におけるソリューションドメイン
19. デザインパターンの共通性・可変性 (一部) 言語機能の共通性・可変性に加えて、より様々な共通性・可変性を表現することが出 来る。 共通性 可変性 機能 振る舞い 細かい粒度のアルゴリズム Template Method 操作と構造 粗い粒度のアルゴリズム Strategy ※ 実際には共通性・可変性の他にバインディング時期など他にも考慮するポイントがあ る ※ フライウェイトパターンなど、共通性・可変性では扱えないものもある ソリューションドメインにおける共通性と可変性 設計におけるソリューションドメイン
20. ソリューションドメインにおける共通性と可変性 設計におけるソリューションドメイン
21. 共通性・可変性の話からわかること 問題ドメインとソリューションドメインそれぞれの共通性・可変性を照らし合わ せることで解決構造を導くことができる プログラミング言語ごとに共通性・可変性の表現の仕方は変わる どの解決手段を選択するかで解決構造は変わる なので、設計においてソリューションドメインは決して無視することができない 存在 ソリューションドメインにおける共通性と可変性 設計におけるソリューションドメイン
22. 解決手段の選択 解決手段の選択 設計におけるソリューションドメイン
23. 適した解決手段を選ぶために大切なこと 問題を理解する 解決手段の引き出しを増やす 解決手段の特性を理解する 解決手段の選択 設計におけるソリューションドメイン
24. 問題の理解 解決手段の選択 設計におけるソリューションドメイン
25. 問題を理解していない場合 そもそも解決構造をまともに考えることができない 解決手段の良し悪しが判断する根拠が持てない 問題ドメインの話なので今回はスルー 解決手段の選択 設計におけるソリューションドメイン
26. 解決手段の引き出し 解決手段の選択 設計におけるソリューションドメイン
27. 解決手段の引き出しが少ない場合 解決構造が必要以上に複雑になる可能性 解決手段の選択 設計におけるソリューションドメイン
28. 負の可変性 負の可変性 設計におけるソリューションドメイン
29. 負の可変性とは 可変性の中でも共通性を侵害する可変性。 基本的に好ましくないため、ドメインの分割や抽象の再定義などを行って排除する。 小さい負の可変性に関してはデザインパターンが解消してくれることも。 負の可変性 設計におけるソリューションドメイン
30. 歪になってしまっているロジック class Contact { public function run(array $input) { // お問い合わせのためになんやかんやする // テストの時以外はSlack 通知をする(= アルゴリズムの負の可変性 if (! $this->env->isTest()) { $this->slack->send($content); } } } 負の可変性 設計におけるソリューションドメイン
31. interface SlackInterface { public function send(string $content): void; } class Slack implements SlackInterface { public function send(string $content): void { // 実際に通知する } } class NullSlack implements SlackInterface { public function send(string $content): void { // 何もしない } } 負の可変性 設計におけるソリューションドメイン
32. Null Object パターンによって負の可変性(if 文)が消え る class Contact { private SlackInterface $slack; public function run(array $input) { // お問い合わせのためになんやかんやする // テスト時は何もしないNullSlack のsend メソッドを実行するだけなので // if 文で分岐する必要がなくなる $this->slack->send($content); } } 負の可変性 設計におけるソリューションドメイン
33. 負の可変性の話からわかること 知っていれば簡単だけど、知らないと難しい問題というものがわりとある ソリューションドメインの知識はより良い解決構造を支援してくれる 負の可変性 設計におけるソリューションドメイン
34. 解決手段の引き出しが多いと 解決構造をより単純にできる可能性が高まる ライブラリや SaaS などに問題の解決を任せることで開発工数を減らせる可能性が 高まる 負の可変性 設計におけるソリューションドメイン
35. 解決手段の特性 解決手段の特性 設計におけるソリューションドメイン
36. 解決手段の特性 解決手段には必ず特性があり、解決手段を採用する状況によってそれがメリットにな ったりデメリットになったりする。 解決手段の特性 設計におけるソリューションドメイン
37. 解決手段の特性が理解できていない場合 オーバースペック/アンダースペックな技術を導入してしまう可能性 避けられた複雑性が発生する可能性 解決手段の特性 設計におけるソリューションドメイン
38. レイヤードアーキテクチャ で考えてみる 特性 アプリケーションを関心ごとに水平に分割することでレイヤ化する 特性がデメリットになる状況 レイヤ化しなくても複雑度が許容できるレベルの場合は、不要な間接層が生まれ るだけになる -> オーバースペックになってしまっている 解決手段の特性 設計におけるソリューションドメイン
39. Active Record で考えてみる データモデルとドメインモデルを同一に扱う 同一に扱うため、データモデルとしての正しさとドメインモデルとしての正しさ という 2 つの関心のバランスを取る必要がある 特性がデメリットになる状況 データモデルに対する要求が増えたりなどすると、ドメインモデルとデータモデ ルの望ましい形が乖離しバランスが取れなくなる -> 避けられた複雑性が発生してしまっている 解決手段の特性 設計におけるソリューションドメイン
40. 解決手段の特性を理解できていると 問題に適した解決手段を選択することができる ただし問題ドメインをちゃんと理解しているというのが前提 本質的でない複雑性と戦わずに済む 解決手段の特性 設計におけるソリューションドメイン
41. まとめ ソリューションドメインとは問題を解決する手段に関するドメイン ソリューションドメイン自体が設計という行為に大きな影響力をもっている 解決手段それぞれに特性があり、問題ドメインとの組み合わせによってはその特 性が新しい問題(複雑性)に発展することがある 良い技術選定・設計をするためには、ソリューションドメインの広く深い理解が 必要 上手に設計したい人は貪欲に様々な技術を学び特性を把握する必要があるのじ ゃ... まとめ 設計におけるソリューションドメイン
42. We are Hiring !!