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
What's new in Spring Modulith?
olivergierke
1
150
Introducing ReActionView: A new ActionView-Compatible ERB Engine @ Kaigi on Rails 2025, Tokyo, Japan
marcoroth
3
1k
Serena MCPのすすめ
wadakatu
4
1k
Software Architecture
hschwentner
6
2.3k
『毎日の移動』を支えるGoバックエンド内製開発
yutautsugi
2
250
タスクの特性や不確実性に応じた最適な作業スタイルの選択(ペアプロ・モブプロ・ソロプロ)と実践 / Optimal Work Style Selection: Pair, Mob, or Solo Programming.
honyanya
3
170
Go Conference 2025: Goで体感するMultipath TCP ― Go 1.24 時代の MPTCP Listener を理解する
takehaya
9
1.7k
AIと人間の共創開発!OSSで試行錯誤した開発スタイル
mae616
1
210
Leading Effective Engineering Teams in the AI Era
addyosmani
5
420
Goで実践するドメイン駆動開発 AIと歩み始めた新規プロダクト開発の現在地
imkaoru
4
840
AI Coding Meetup #3 - 導入セッション / ai-coding-meetup-3
izumin5210
0
3.3k
Web Components で実現する Hotwire とフロントエンドフレームワークの橋渡し / Bridging with Web Components
da1chi
3
2.5k
Featured
See All Featured
The Illustrated Children's Guide to Kubernetes
chrisshort
49
51k
Being A Developer After 40
akosma
91
590k
Imperfection Machines: The Place of Print at Facebook
scottboms
269
13k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.7k
Optimizing for Happiness
mojombo
379
70k
Embracing the Ebb and Flow
colly
88
4.8k
Building Adaptive Systems
keathley
44
2.8k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
16
1.7k
Into the Great Unknown - MozCon
thekraken
40
2.1k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
140
34k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
35
6.1k
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化し た感も有る • 設計を後回しにしたことで首が締まったことも多い • 複雑なシステムこそ、時間が無くともきちんと設計 すべき
ご清聴ありがとうございました