Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

自己紹介 名前: 吉田あひる (@strtyuu) 所属: スターフェスティバル株式会社 仕事: バックエンドエンジニア 焼肉を奢らない人です Laravel.shibuya というイベントを共同運営しています。 はじめに 設計におけるソリューションドメイン

Slide 3

Slide 3 text

このセッションについて 設計というアクティビティにおけるソリューションドメインの重要性を改めて整理し て初心(?)にかえろうという試みです。 ※ 論理的なモデルに憧れすぎて技術を若干軽視した考え方になっていた頃の自分へ伝え たい内容となっております はじめに 設計におけるソリューションドメイン

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

解決構造の導き方 解決構造の導き方 設計におけるソリューションドメイン

Slide 9

Slide 9 text

ここでいう解決構造とは 問題を解決するために構築されたモデルや実装のこと 解決構造の導き方 設計におけるソリューションドメイン

Slide 10

Slide 10 text

共通性と可変性 共通性と可変性 設計におけるソリューションドメイン

Slide 11

Slide 11 text

共通性 複数のモノやコトに共通する部分 データ構造 振る舞い アルゴリズム etc... 共通性と可変性 設計におけるソリューションドメイン

Slide 12

Slide 12 text

データ構造の共通性 EC サイトの商品であれば、全ての商品は 商品名 商品説明 価格 といったデータを持つなど 共通性と可変性 設計におけるソリューションドメイン

Slide 13

Slide 13 text

振る舞いの共通性 例えば電話を考えたときに、黒電話であってもスマホであっても 着信があればそれを知らせる 通話のためのコネクションを確立する という共通する振る舞いをもつなど 共通性と可変性 設計におけるソリューションドメイン

Slide 14

Slide 14 text

アルゴリズムの共通性 クイックソートであれば 1.基準値を決める 2.基準値より大きいグループと小さいグループに分ける 3.分けたグループに対して同じことを繰り返す という、並び替える対象に影響されない手順自体の共通性など 共通性と可変性 設計におけるソリューションドメイン

Slide 15

Slide 15 text

可変性 共通性という枠組みの中で可変する部分 データ構造が共通していても値(状態)は可変 振る舞いは共通していても実装は可変 など 共通性と可変性 設計におけるソリューションドメイン

Slide 16

Slide 16 text

ソリューションドメインにおける共通性と可変性 ソリューションドメインにおける共通性と可変性 設計におけるソリューションドメイン

Slide 17

Slide 17 text

共通性と可変性を扱える解決手段 プログラミング言語 一部のデザインパターン ライブラリ(今回は取り上げません) ソリューションドメインにおける共通性と可変性 設計におけるソリューションドメイン

Slide 18

Slide 18 text

PHP が表現できる共通性・可変性 (一部) 共通性 可変性 機能 振る舞い・データ構造 状態 Class 名前(意味) or 振る舞い 振る舞い or 実装 Interface 振る舞い 型 Trait データ構造 小さい値の組 Enum ※ 実際には共通性・可変性の他にバインディング時期など他にも考慮するポイントがあ る ソリューションドメインにおける共通性と可変性 設計におけるソリューションドメイン

Slide 19

Slide 19 text

デザインパターンの共通性・可変性 (一部) 言語機能の共通性・可変性に加えて、より様々な共通性・可変性を表現することが出 来る。 共通性 可変性 機能 振る舞い 細かい粒度のアルゴリズム Template Method 操作と構造 粗い粒度のアルゴリズム Strategy ※ 実際には共通性・可変性の他にバインディング時期など他にも考慮するポイントがあ る ※ フライウェイトパターンなど、共通性・可変性では扱えないものもある ソリューションドメインにおける共通性と可変性 設計におけるソリューションドメイン

Slide 20

Slide 20 text

ソリューションドメインにおける共通性と可変性 設計におけるソリューションドメイン

Slide 21

Slide 21 text

共通性・可変性の話からわかること 問題ドメインとソリューションドメインそれぞれの共通性・可変性を照らし合わ せることで解決構造を導くことができる プログラミング言語ごとに共通性・可変性の表現の仕方は変わる どの解決手段を選択するかで解決構造は変わる なので、設計においてソリューションドメインは決して無視することができない 存在 ソリューションドメインにおける共通性と可変性 設計におけるソリューションドメイン

Slide 22

Slide 22 text

解決手段の選択 解決手段の選択 設計におけるソリューションドメイン

Slide 23

Slide 23 text

適した解決手段を選ぶために大切なこと 問題を理解する 解決手段の引き出しを増やす 解決手段の特性を理解する 解決手段の選択 設計におけるソリューションドメイン

Slide 24

Slide 24 text

問題の理解 解決手段の選択 設計におけるソリューションドメイン

Slide 25

Slide 25 text

問題を理解していない場合 そもそも解決構造をまともに考えることができない 解決手段の良し悪しが判断する根拠が持てない 問題ドメインの話なので今回はスルー 解決手段の選択 設計におけるソリューションドメイン

Slide 26

Slide 26 text

解決手段の引き出し 解決手段の選択 設計におけるソリューションドメイン

Slide 27

Slide 27 text

解決手段の引き出しが少ない場合 解決構造が必要以上に複雑になる可能性 解決手段の選択 設計におけるソリューションドメイン

Slide 28

Slide 28 text

負の可変性 負の可変性 設計におけるソリューションドメイン

Slide 29

Slide 29 text

負の可変性とは 可変性の中でも共通性を侵害する可変性。 基本的に好ましくないため、ドメインの分割や抽象の再定義などを行って排除する。 小さい負の可変性に関してはデザインパターンが解消してくれることも。 負の可変性 設計におけるソリューションドメイン

Slide 30

Slide 30 text

歪になってしまっているロジック class Contact { public function run(array $input) { // お問い合わせのためになんやかんやする // テストの時以外はSlack 通知をする(= アルゴリズムの負の可変性 if (! $this->env->isTest()) { $this->slack->send($content); } } } 負の可変性 設計におけるソリューションドメイン

Slide 31

Slide 31 text

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 { // 何もしない } } 負の可変性 設計におけるソリューションドメイン

Slide 32

Slide 32 text

Null Object パターンによって負の可変性(if 文)が消え る class Contact { private SlackInterface $slack; public function run(array $input) { // お問い合わせのためになんやかんやする // テスト時は何もしないNullSlack のsend メソッドを実行するだけなので // if 文で分岐する必要がなくなる $this->slack->send($content); } } 負の可変性 設計におけるソリューションドメイン

Slide 33

Slide 33 text

負の可変性の話からわかること 知っていれば簡単だけど、知らないと難しい問題というものがわりとある ソリューションドメインの知識はより良い解決構造を支援してくれる 負の可変性 設計におけるソリューションドメイン

Slide 34

Slide 34 text

解決手段の引き出しが多いと 解決構造をより単純にできる可能性が高まる ライブラリや SaaS などに問題の解決を任せることで開発工数を減らせる可能性が 高まる 負の可変性 設計におけるソリューションドメイン

Slide 35

Slide 35 text

解決手段の特性 解決手段の特性 設計におけるソリューションドメイン

Slide 36

Slide 36 text

解決手段の特性 解決手段には必ず特性があり、解決手段を採用する状況によってそれがメリットにな ったりデメリットになったりする。 解決手段の特性 設計におけるソリューションドメイン

Slide 37

Slide 37 text

解決手段の特性が理解できていない場合 オーバースペック/アンダースペックな技術を導入してしまう可能性 避けられた複雑性が発生する可能性 解決手段の特性 設計におけるソリューションドメイン

Slide 38

Slide 38 text

レイヤードアーキテクチャ で考えてみる 特性 アプリケーションを関心ごとに水平に分割することでレイヤ化する 特性がデメリットになる状況 レイヤ化しなくても複雑度が許容できるレベルの場合は、不要な間接層が生まれ るだけになる -> オーバースペックになってしまっている 解決手段の特性 設計におけるソリューションドメイン

Slide 39

Slide 39 text

Active Record で考えてみる データモデルとドメインモデルを同一に扱う 同一に扱うため、データモデルとしての正しさとドメインモデルとしての正しさ という 2 つの関心のバランスを取る必要がある 特性がデメリットになる状況 データモデルに対する要求が増えたりなどすると、ドメインモデルとデータモデ ルの望ましい形が乖離しバランスが取れなくなる -> 避けられた複雑性が発生してしまっている 解決手段の特性 設計におけるソリューションドメイン

Slide 40

Slide 40 text

解決手段の特性を理解できていると 問題に適した解決手段を選択することができる ただし問題ドメインをちゃんと理解しているというのが前提 本質的でない複雑性と戦わずに済む 解決手段の特性 設計におけるソリューションドメイン

Slide 41

Slide 41 text

まとめ ソリューションドメインとは問題を解決する手段に関するドメイン ソリューションドメイン自体が設計という行為に大きな影響力をもっている 解決手段それぞれに特性があり、問題ドメインとの組み合わせによってはその特 性が新しい問題(複雑性)に発展することがある 良い技術選定・設計をするためには、ソリューションドメインの広く深い理解が 必要 上手に設計したい人は貪欲に様々な技術を学び特性を把握する必要があるのじ ゃ... まとめ 設計におけるソリューションドメイン

Slide 42

Slide 42 text

We are Hiring !!