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
philomagi
July 30, 2019
Programming
0
130
混沌からドメインモデルへ
カオスな実装のプロジェクトにおいて
カオス → Fat Model
Fat Model → ドメインモデル
と段階を経て、リファクタリングに取り組んだ試み
philomagi
July 30, 2019
Tweet
Share
More Decks by philomagi
See All by philomagi
ドメイン駆動設計のホーリズム的側面 / domain-driven-design and holism
tooppoo
0
190
アート、サイエンス、「わかりやすさ」 / art, science, "easy to understand"
tooppoo
1
20k
ソフトウェアと「動的平衡」 / software-and-dynamic-equilibrium
tooppoo
1
1k
javascriptでも条件式を使いたい話 / want to use conditional expression in javascript
tooppoo
0
6.4k
Fat ComponentにしないためのWebフロントエンド設計 / Web Front-End design to avoid being a Fat Component
tooppoo
4
3.6k
技術書・方法論とのお付き合い / how to learn theory
tooppoo
4
1.2k
「オブジェクト指向」を再考する / reconsider "object-oriented"
tooppoo
2
820
「モデル」の二面性と設計を考える / dual nature of "model"
tooppoo
2
1.8k
「ドメイン」駆動で考える「ドメイン駆動設計」/consideration of domain-driven design via domain
tooppoo
9
2.9k
Other Decks in Programming
See All in Programming
なぜGoのジェネリクスはこの形なのか? Featherweight Goが明かす設計の核心
ryotaros
7
1.1k
Goで実践するドメイン駆動開発 AIと歩み始めた新規プロダクト開発の現在地
imkaoru
4
850
株式会社 Sun terras カンパニーデック
sunterras
0
320
タスクの特性や不確実性に応じた最適な作業スタイルの選択(ペアプロ・モブプロ・ソロプロ)と実践 / Optimal Work Style Selection: Pair, Mob, or Solo Programming.
honyanya
3
180
Introduce Hono CLI
yusukebe
5
2.1k
20251016_Rails News ~Rails 8.1の足音を聴く~
morimorihoge
2
380
CSC509 Lecture 05
javiergs
PRO
0
300
コードとあなたと私の距離 / The Distance Between Code, You, and I
hiro_y
0
170
登壇は dynamic! な営みである / speech is dynamic
da1chi
0
340
Six and a half ridiculous things to do with Quarkus
hollycummins
0
180
アメ車でサンノゼを走ってきたよ!
s_shimotori
0
230
なぜあの開発者はDevRelに伴走し続けるのか / Why Does That Developer Keep Running Alongside DevRel?
nrslib
3
410
Featured
See All Featured
How to Think Like a Performance Engineer
csswizardry
27
2k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
How to Ace a Technical Interview
jacobian
280
24k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.5k
GraphQLとの向き合い方2022年版
quramy
49
14k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
230
22k
Statistics for Hackers
jakevdp
799
220k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Designing for humans not robots
tammielis
254
26k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
33
2.3k
BBQ
matthewcrist
89
9.8k
Faster Mobile Websites
deanohume
310
31k
Transcript
混沌からドメインモデルへ 段階的リファクタリングの試み 2019/07/30@設計会議
発表者 topo / @Philomagi • 主にフロントエンド主体のWEB系エンジニア • ScalaとTypescriptとRubyが好き ◦ Rubyは最近、公私共に若干疎遠
• PHPは中々縁が切れない悪友 ◦ 最近は、そう腐すほどでもないかなと思い始めてる
概要 • 設計が存在しないプロジェクト • 既存コードが色々とアレ • まずはFat Modelで手元を見えるように • 道具を揃えてからドメインモデルへ
1. 混沌
混沌とした状況 • コードの重複 • モデル貧血症 • 詳細に依存 • UtilityじゃないUtil
カプセル化?なにそれ美味しいの? $props = Hash::extract($item->get('props'), "{n}[name=/^{$propName}[.]/]" ※Viewのコード(イメージ)
カプセル化?なにそれ美味しいの? return [ 'stock.enough' => $item->get('stock.amount') >= 10, // 中略
'status.hoge' => count($item->extract("props.{n}[name={$hogeStatusName}]")) >= 1, ]; ※Utilのコード(イメージ)
View Controller Util Model Hash
View Controller Util Model Hash • Fat View(Smart UI) •
Fat Controller • Fat Util • 貧血モデル
2. 混沌からFat Modelへ
Why Fat Model? • 次々に飛んでくる回収要望・追加機能 ◦ モデル分析のための時間も体力も確保し難い • 取り敢えず、直近触るコードだけでも見通しよくした い
Fat Modelへ • ロジックをDTOへ集約 • 詳細へのアクセスをメソッド経由に • 必要に応じてValueObjectも追加 • Utilは基本的に削除
◦ 入り組んでるものは、可能ならModel経由の利用に変更
Before / After $props = Hash::extract($item->get('props'), "{n}[name=/^{$propName}[.]/]" $sizes = $item->getSizesWhere($sizeName);
Before / After return [ 'stock.enough' => $item->get('stock.amount') >= 10,
// 中略 'status.hoge' => count($item->extract("props.{n}[name={$hogeStatus}]")) >= 1, ]; return [ 'stock.enough' => $item>stock()->isEnough(), // 中略 'status.hoge' => $item>isHoge(), ];
View Controller Util Model Hash
View Controller Util Model Hash • Fat Model
3. Fat Model から Domain Model へ
• モデルを描いて共有 ◦ 仕様を握っている人と認識を揃える • 語彙を統一 ◦ DDDにおけるユビキタス言語 • 部分的に、使えるところから導入開始
◦ 一気の置き換えは狙わない Domain Model の導入
Domain Object の実装 • 統一した語彙を、クラス名/メソッド名で使用する • データとDomain Objectの分離 ◦ DTO
→ Domain Objectのマッピング層を用意 ◦ Factory、Repository • Modelに集約したロジックをDomain Objectに移動 ◦ ModelはただのDTOになり、ロジックはDomain Objectが持つ • パッケージでコンテクストを表現 ◦ パッケージ内のオブジェクトは、ひたすらそのコンテクストに特化
View Controller DomainObject DomainObject View Controller DomainObject View Controller Mapping
Infrastructure Model(DTO) Mapping Mapping
振り返って プラマイ両方有ったが、マイナスが強い • 「何が用意してあるのか」「何が用意されてないのか」を確認 できる • 「とりあえず読めなくはない」には持っていける • Modelに強く依存した実装になってしまう ◦
DTOがプロジェクト全体を支配してしまうため
評価 • 今回はとにかくスタート地点が真っ暗闇だった • まずは手元に何が有り、何が無いのかを把握したかった • 今回のケースでは、一定程度の妥当性は有ったかなと感じて いる • 決して、Bestなプロセスでは無いと思う
◦ 緊急回避的 ◦ 経由せずに済むなら経由しない方が良い
反省点 • 「設計しない」ための言い訳としてFat Model化し た感も有る • 設計を後回しにしたことで首が締まったことも多い • 複雑なシステムこそ、時間が無くともきちんと設計 すべき
ご清聴ありがとうございました