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
97
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
技術的負債の正体を知って向き合う
irof
0
190
スキーマ駆動で、Zod OpenAPI Honoによる、API開発するために、Hono Takibiというライブラリを作っている
nakita628
0
150
CSC509 Lecture 03
javiergs
PRO
0
340
Building, Deploying, and Monitoring Ruby Web Applications with Falcon (Kaigi on Rails 2025)
ioquatix
4
2.2k
いま中途半端なSwift 6対応をするより、Default ActorやApproachable Concurrencyを有効にしてからでいいんじゃない?
yimajo
2
440
(Extension DC 2025) Actor境界を越える技術
teamhimeh
1
260
monorepo の Go テストをはやくした〜い!~最小の依存解決への道のり~ / faster-testing-of-monorepos
convto
2
500
私達はmodernize packageに夢を見るか feat. go/analysis, go/ast / Go Conference 2025
kaorumuta
2
600
Foundation Modelsを実装日本語学習アプリを作ってみた!
hypebeans
0
120
Serena MCPのすすめ
wadakatu
4
1k
The Past, Present, and Future of Enterprise Java
ivargrimstad
0
440
はじめてのDSPy - 言語モデルを『プロンプト』ではなく『プログラミング』するための仕組み
masahiro_nishimi
2
610
Featured
See All Featured
Speed Design
sergeychernyshev
32
1.2k
Building a Modern Day E-commerce SEO Strategy
aleyda
44
7.8k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.2k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
21
1.2k
YesSQL, Process and Tooling at Scale
rocio
173
14k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.2k
Mobile First: as difficult as doing things right
swwweet
225
10k
Designing for humans not robots
tammielis
254
26k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
190
55k
A Tale of Four Properties
chriscoyier
161
23k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
10
870
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.6k
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って最高
ご静聴 ありがとうございました