Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
設計におけるソリューションドメイン
Search
y_ahiru
April 09, 2022
3
1.5k
設計におけるソリューションドメイン
y_ahiru
April 09, 2022
Tweet
Share
More Decks by y_ahiru
See All by y_ahiru
フロントエンドエンジニアも知っておきたい HTTP/3 で変わること
yahiru
16
12k
ゆるふわCQRS入門
yahiru
2
540
PHPで始めるGitHub Actions
yahiru
1
700
5ヶ月でカバレッジを20%から90%にあげた話
yahiru
2
6.5k
入門ミューテーションテスト/ A bigginer's guide to Mutation testing
yahiru
0
1.4k
Eloquentに別れを告げるタイミングについて考えた
yahiru
2
1.9k
DDDについて勉強したので5分でまとめる
yahiru
0
300
Featured
See All Featured
Ruby is Unlike a Banana
tanoku
97
11k
Into the Great Unknown - MozCon
thekraken
32
1.5k
Happy Clients
brianwarren
98
6.7k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.9k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.3k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
Automating Front-end Workflow
addyosmani
1366
200k
How to Ace a Technical Interview
jacobian
276
23k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
131
33k
Designing on Purpose - Digital PM Summit 2013
jponch
115
7k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
329
21k
Transcript
設計におけるソリューションドメイン 吉田あひる
自己紹介 名前: 吉田あひる (@strtyuu) 所属: スターフェスティバル株式会社 仕事: バックエンドエンジニア 焼肉を奢らない人です Laravel.shibuya
というイベントを共同運営しています。 はじめに 設計におけるソリューションドメイン
このセッションについて 設計というアクティビティにおけるソリューションドメインの重要性を改めて整理し て初心(?)にかえろうという試みです。 ※ 論理的なモデルに憧れすぎて技術を若干軽視した考え方になっていた頃の自分へ伝え たい内容となっております はじめに 設計におけるソリューションドメイン
ソリューションドメインとは ソリューションドメインとは 設計におけるソリューションドメイン
ソリューションドメインとは 設計におけるソリューションドメイン
ソリューションドメインとは 設計におけるソリューションドメイン
ソリューションドメインとは 設計におけるソリューションドメイン
解決構造の導き方 解決構造の導き方 設計におけるソリューションドメイン
ここでいう解決構造とは 問題を解決するために構築されたモデルや実装のこと 解決構造の導き方 設計におけるソリューションドメイン
共通性と可変性 共通性と可変性 設計におけるソリューションドメイン
共通性 複数のモノやコトに共通する部分 データ構造 振る舞い アルゴリズム etc... 共通性と可変性 設計におけるソリューションドメイン
データ構造の共通性 EC サイトの商品であれば、全ての商品は 商品名 商品説明 価格 といったデータを持つなど 共通性と可変性 設計におけるソリューションドメイン
振る舞いの共通性 例えば電話を考えたときに、黒電話であってもスマホであっても 着信があればそれを知らせる 通話のためのコネクションを確立する という共通する振る舞いをもつなど 共通性と可変性 設計におけるソリューションドメイン
アルゴリズムの共通性 クイックソートであれば 1.基準値を決める 2.基準値より大きいグループと小さいグループに分ける 3.分けたグループに対して同じことを繰り返す という、並び替える対象に影響されない手順自体の共通性など 共通性と可変性 設計におけるソリューションドメイン
可変性 共通性という枠組みの中で可変する部分 データ構造が共通していても値(状態)は可変 振る舞いは共通していても実装は可変 など 共通性と可変性 設計におけるソリューションドメイン
ソリューションドメインにおける共通性と可変性 ソリューションドメインにおける共通性と可変性 設計におけるソリューションドメイン
共通性と可変性を扱える解決手段 プログラミング言語 一部のデザインパターン ライブラリ(今回は取り上げません) ソリューションドメインにおける共通性と可変性 設計におけるソリューションドメイン
PHP が表現できる共通性・可変性 (一部) 共通性 可変性 機能 振る舞い・データ構造 状態 Class 名前(意味)
or 振る舞い 振る舞い or 実装 Interface 振る舞い 型 Trait データ構造 小さい値の組 Enum ※ 実際には共通性・可変性の他にバインディング時期など他にも考慮するポイントがあ る ソリューションドメインにおける共通性と可変性 設計におけるソリューションドメイン
デザインパターンの共通性・可変性 (一部) 言語機能の共通性・可変性に加えて、より様々な共通性・可変性を表現することが出 来る。 共通性 可変性 機能 振る舞い 細かい粒度のアルゴリズム Template
Method 操作と構造 粗い粒度のアルゴリズム Strategy ※ 実際には共通性・可変性の他にバインディング時期など他にも考慮するポイントがあ る ※ フライウェイトパターンなど、共通性・可変性では扱えないものもある ソリューションドメインにおける共通性と可変性 設計におけるソリューションドメイン
ソリューションドメインにおける共通性と可変性 設計におけるソリューションドメイン
共通性・可変性の話からわかること 問題ドメインとソリューションドメインそれぞれの共通性・可変性を照らし合わ せることで解決構造を導くことができる プログラミング言語ごとに共通性・可変性の表現の仕方は変わる どの解決手段を選択するかで解決構造は変わる なので、設計においてソリューションドメインは決して無視することができない 存在 ソリューションドメインにおける共通性と可変性 設計におけるソリューションドメイン
解決手段の選択 解決手段の選択 設計におけるソリューションドメイン
適した解決手段を選ぶために大切なこと 問題を理解する 解決手段の引き出しを増やす 解決手段の特性を理解する 解決手段の選択 設計におけるソリューションドメイン
問題の理解 解決手段の選択 設計におけるソリューションドメイン
問題を理解していない場合 そもそも解決構造をまともに考えることができない 解決手段の良し悪しが判断する根拠が持てない 問題ドメインの話なので今回はスルー 解決手段の選択 設計におけるソリューションドメイン
解決手段の引き出し 解決手段の選択 設計におけるソリューションドメイン
解決手段の引き出しが少ない場合 解決構造が必要以上に複雑になる可能性 解決手段の選択 設計におけるソリューションドメイン
負の可変性 負の可変性 設計におけるソリューションドメイン
負の可変性とは 可変性の中でも共通性を侵害する可変性。 基本的に好ましくないため、ドメインの分割や抽象の再定義などを行って排除する。 小さい負の可変性に関してはデザインパターンが解消してくれることも。 負の可変性 設計におけるソリューションドメイン
歪になってしまっているロジック class Contact { public function run(array $input) { //
お問い合わせのためになんやかんやする // テストの時以外はSlack 通知をする(= アルゴリズムの負の可変性 if (! $this->env->isTest()) { $this->slack->send($content); } } } 負の可変性 設計におけるソリューションドメイン
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 { // 何もしない } } 負の可変性 設計におけるソリューションドメイン
Null Object パターンによって負の可変性(if 文)が消え る class Contact { private SlackInterface
$slack; public function run(array $input) { // お問い合わせのためになんやかんやする // テスト時は何もしないNullSlack のsend メソッドを実行するだけなので // if 文で分岐する必要がなくなる $this->slack->send($content); } } 負の可変性 設計におけるソリューションドメイン
負の可変性の話からわかること 知っていれば簡単だけど、知らないと難しい問題というものがわりとある ソリューションドメインの知識はより良い解決構造を支援してくれる 負の可変性 設計におけるソリューションドメイン
解決手段の引き出しが多いと 解決構造をより単純にできる可能性が高まる ライブラリや SaaS などに問題の解決を任せることで開発工数を減らせる可能性が 高まる 負の可変性 設計におけるソリューションドメイン
解決手段の特性 解決手段の特性 設計におけるソリューションドメイン
解決手段の特性 解決手段には必ず特性があり、解決手段を採用する状況によってそれがメリットにな ったりデメリットになったりする。 解決手段の特性 設計におけるソリューションドメイン
解決手段の特性が理解できていない場合 オーバースペック/アンダースペックな技術を導入してしまう可能性 避けられた複雑性が発生する可能性 解決手段の特性 設計におけるソリューションドメイン
レイヤードアーキテクチャ で考えてみる 特性 アプリケーションを関心ごとに水平に分割することでレイヤ化する 特性がデメリットになる状況 レイヤ化しなくても複雑度が許容できるレベルの場合は、不要な間接層が生まれ るだけになる -> オーバースペックになってしまっている 解決手段の特性
設計におけるソリューションドメイン
Active Record で考えてみる データモデルとドメインモデルを同一に扱う 同一に扱うため、データモデルとしての正しさとドメインモデルとしての正しさ という 2 つの関心のバランスを取る必要がある 特性がデメリットになる状況 データモデルに対する要求が増えたりなどすると、ドメインモデルとデータモデ
ルの望ましい形が乖離しバランスが取れなくなる -> 避けられた複雑性が発生してしまっている 解決手段の特性 設計におけるソリューションドメイン
解決手段の特性を理解できていると 問題に適した解決手段を選択することができる ただし問題ドメインをちゃんと理解しているというのが前提 本質的でない複雑性と戦わずに済む 解決手段の特性 設計におけるソリューションドメイン
まとめ ソリューションドメインとは問題を解決する手段に関するドメイン ソリューションドメイン自体が設計という行為に大きな影響力をもっている 解決手段それぞれに特性があり、問題ドメインとの組み合わせによってはその特 性が新しい問題(複雑性)に発展することがある 良い技術選定・設計をするためには、ソリューションドメインの広く深い理解が 必要 上手に設計したい人は貪欲に様々な技術を学び特性を把握する必要があるのじ ゃ... まとめ
設計におけるソリューションドメイン
We are Hiring !!