DDD失敗談

Transcript

1. DDD失敗談 @paraya3636(ぱらや)
2. paraya3636(みうら) @paraya3636(ぱらや) # 直近やってたこと - iOS　 3年 - Android 2年半 - CleanArchitecture(DDD) 2年
3. DDD失敗談
4. 僕が考えていた DDDへの幻想
5. # DDDで一度設計すれば変更は少ない # ユビキタス(共通)言語は不変 # ロジックはドメインレイヤーに書けばよい
6. DDDで一度設計すれば 変更は少ない
7. そんなことはなかった
8. NG: DDDで一度設計してしまえば変更は少ない # ドメインの設計見直しタイミング - 他の仕様に引きづられて仕様が変わる - ユーザテストの意見反映で仕様が変わる - 実装を進めていてより良い設計を思いついた # 意外とコロコロ変わる 悩んでベスト設計を目指すのはNG。 ベター設計で速度を優先したほうが良い。
9. ユビキタス(共通)言語は 不変
10. そんなことはなかった
11. NG: ユビキタス(共通)言語は不変 # ユビキタス言語が変わるタイミング - デザイン進めて行く上で変わった - 他アプリでの名称違うからそっちの反映 - 気付いたら自然と変わってた # 定着するまで変わることがある 変わらないように努めるべき。 だが、変わる可能性は充分にあることを留意する。 変わってもイライラしない。
12. ロジックはドメインレイヤーに 書けばよい
13. これは少し掘り下げて話しま す
14. NG: ロジックはドメインレイヤーに書けばよい # 間違ってはいないが設計がふわっとしてる - ふわっとしたまま実装するとミスを誘発する # 実際に起きた問題 - ビジネスロジックどこ書けばいいかわからん… - 一旦ユースケースにメソッド書くか - →Entityがただのデータの入れ物化
15. ドメインモデル貧血症
16. メソッドが存在しないドメインモ デルがある →でもロジック書きたい NG: ユースケースに書く
17. ユースケース肥大化 共通ロジックとして使いづらい ドメインモデル
18. ドメインモデル貧血症 # データの入れ物自身が振る舞う事を意識する - 1. Entityに書けるか？ - 2. ValueObjectに書けるか？ - 3. 振る舞いだけを持つServiceに書く # ユースケースにロジックは書かない - ユースケースではドメインモデルのロジックの呼び出し 順序でロジックの流れを表現する
19. 思っていたDDDとはちょっと 違ったけど
20. でもDDDって最高
21. ご静聴 ありがとうございました