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
DDD失敗談
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Paraya
June 21, 2017
Programming
0
140
DDD失敗談
Paraya
June 21, 2017
Tweet
Share
More Decks by Paraya
See All by Paraya
J2K failure story : UNIT
paraya3636
0
110
J2Kコンバータをカスタマイズする ver: 5min
paraya3636
0
1.8k
J2Kコンバータをカスタマイズする
paraya3636
1
2.2k
命名おじさん
paraya3636
1
170
Step up Kotlin
paraya3636
0
97
Other Decks in Programming
See All in Programming
16年目のピクシブ百科事典を支える最新の技術基盤 / The Modern Tech Stack Powering Pixiv Encyclopedia in its 16th Year
ahuglajbclajep
5
1k
AWS re:Invent 2025参加 直前 Seattle-Tacoma Airport(SEA)におけるハードウェア紛失インシデントLT
tetutetu214
2
120
Oxlint JS plugins
kazupon
1
980
KIKI_MBSD Cybersecurity Challenges 2025
ikema
0
1.3k
Raku Raku Notion 20260128
hareyakayuruyaka
0
340
AI によるインシデント初動調査の自動化を行う AI インシデントコマンダーを作った話
azukiazusa1
1
740
副作用をどこに置くか問題:オブジェクト指向で整理する設計判断ツリー
koxya
1
610
CSC307 Lecture 09
javiergs
PRO
1
840
React 19でつくる「気持ちいいUI」- 楽観的UIのすすめ
himorishige
11
7.4k
Architectural Extensions
denyspoltorak
0
290
SourceGeneratorのススメ
htkym
0
200
Oxlintはいいぞ
yug1224
5
1.3k
Featured
See All Featured
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
16k
Embracing the Ebb and Flow
colly
88
5k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
54k
Design in an AI World
tapps
0
140
The Cost Of JavaScript in 2023
addyosmani
55
9.5k
Joys of Absence: A Defence of Solitary Play
codingconduct
1
290
Optimising Largest Contentful Paint
csswizardry
37
3.6k
Public Speaking Without Barfing On Your Shoes - THAT 2023
reverentgeek
1
310
Testing 201, or: Great Expectations
jmmastey
46
8k
The Straight Up "How To Draw Better" Workshop
denniskardys
239
140k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
31
3.1k
Accessibility Awareness
sabderemane
0
53
Transcript
DDD失敗談 @paraya3636(ぱらや)
paraya3636(みうら) @paraya3636(ぱらや) # 直近やってたこと - iOS 3年 - Android 2年半
- CleanArchitecture(DDD) 2年
DDD失敗談
僕が考えていた DDDへの幻想
# DDDで一度設計すれば変更は少ない # ユビキタス(共通)言語は不変 # ロジックはドメインレイヤーに書けばよい
DDDで一度設計すれば 変更は少ない
そんなことはなかった
NG: DDDで一度設計してしまえば変更は少ない # ドメインの設計見直しタイミング - 他の仕様に引きづられて仕様が変わる - ユーザテストの意見反映で仕様が変わる - 実装を進めていてより良い設計を思いついた
# 意外とコロコロ変わる 悩んでベスト設計を目指すのはNG。 ベター設計で速度を優先したほうが良い。
ユビキタス(共通)言語は 不変
そんなことはなかった
NG: ユビキタス(共通)言語は不変 # ユビキタス言語が変わるタイミング - デザイン進めて行く上で変わった - 他アプリでの名称違うからそっちの反映 - 気付いたら自然と変わってた
# 定着するまで変わることがある 変わらないように努めるべき。 だが、変わる可能性は充分にあることを留意する。 変わってもイライラしない。
ロジックはドメインレイヤーに 書けばよい
これは少し掘り下げて話しま す
NG: ロジックはドメインレイヤーに書けばよい # 間違ってはいないが設計がふわっとしてる - ふわっとしたまま実装するとミスを誘発する # 実際に起きた問題 - ビジネスロジックどこ書けばいいかわからん…
- 一旦ユースケースにメソッド書くか - →Entityがただのデータの入れ物化
ドメインモデル貧血症
メソッドが存在しないドメインモ デルがある →でもロジック書きたい NG: ユースケースに書く
ユースケース肥大化 共通ロジックとして使いづらい ドメインモデル
ドメインモデル貧血症 # データの入れ物自身が振る舞う事を意識する - 1. Entityに書けるか? - 2. ValueObjectに書けるか? -
3. 振る舞いだけを持つServiceに書く # ユースケースにロジックは書かない - ユースケースではドメインモデルのロジックの呼び出し 順序でロジックの流れを表現する
思っていたDDDとはちょっと 違ったけど
でもDDDって最高
ご静聴 ありがとうございました