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
Paraya
June 21, 2017
Programming
0
130
DDD失敗談
Paraya
June 21, 2017
Tweet
Share
More Decks by Paraya
See All by Paraya
J2K failure story : UNIT
paraya3636
0
98
J2Kコンバータをカスタマイズする ver: 5min
paraya3636
0
1.8k
J2Kコンバータをカスタマイズする
paraya3636
1
2.2k
命名おじさん
paraya3636
1
160
Step up Kotlin
paraya3636
0
88
Other Decks in Programming
See All in Programming
The Past, Present, and Future of Enterprise Java
ivargrimstad
0
550
なぜあの開発者はDevRelに伴走し続けるのか / Why Does That Developer Keep Running Alongside DevRel?
nrslib
3
420
NIKKEI Tech Talk#38
cipepser
0
110
ALL CODE BASE ARE BELONG TO STUDY
uzulla
27
6.6k
EMこそClaude Codeでコード調査しよう
shibayu36
0
300
ソフトウェア設計の実践的な考え方
masuda220
PRO
4
630
Claude Agent SDK を使ってみよう
hyshu
0
1.3k
Things You Thought You Didn’t Need To Care About That Have a Big Impact On Your Job
hollycummins
0
250
モテるデスク環境
mozumasu
3
900
kiroとCodexで最高のSpec駆動開発を!!数時間で web3ネイティブなミニゲームを作ってみたよ!
mashharuki
0
840
TransformerからMCPまで(現代AIを理解するための羅針盤)
mickey_kubo
4
2.3k
O Que É e Como Funciona o PHP-FPM?
marcelgsantos
0
150
Featured
See All Featured
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
15k
Building Flexible Design Systems
yeseniaperezcruz
329
39k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.7k
The Pragmatic Product Professional
lauravandoore
36
7k
Context Engineering - Making Every Token Count
addyosmani
7
280
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
9
920
Code Review Best Practice
trishagee
72
19k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
30
2.9k
Unsuck your backbone
ammeep
671
58k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
115
20k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
34
2.3k
Scaling GitHub
holman
463
140k
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って最高
ご静聴 ありがとうございました