More Related Content
More from ke-m kamekoopa (15)
設計してますか？
- 11. 心がまえ編 – 実装はあとまわし
仕様変更は概ね人間の感覚の先にしか無い
カート機能に動画共有機能は多分追加されない
哲学、概念、ポリシーの把握、洞察が大事
仕様の実装法より先に行間を洞察する
仕様の背景、既存機能との関連の仕方とか
サービスの在り方とか
洞察したら確認して共通認識に落とし込みま
しょう
- 12. 心がまえ編 – 名前大事
実装ではなく概念から名前を切り出す
機能を日本語でそらんじる
“カートに商品を入れて、カートの中の商品を購入する機能”
“送料無料なら送料は¥0にする”
日本語の中から出てきた言葉、関係性を拾う
“カート”, ”商品”, “購入”, “送料”
コードには概念の名前を使う
×if( !(isValidItemCountAndAmount()) ) {
amount += 525;
}
○ if( ! isFreeShipping() ) {
amount += shipping;
}
- 13. 心がまえ編 – サボらない
既存システムに機能を追加する
このクラスに追加すれば出来る
そのクラスに追加すべきかどうなのか？
クラスが表している概念に沿う
クラスの表す概念外の機能追加は早晩破綻する
「だって適切なクラスがないから」
概念の切り出しに失敗しているかも？
モデリングを見直すチャンスかも？
サボらない！
- 23. 実践編
ありがちなの
User user = User.findById(1);
user.setAge(100);
user.save();
Userクラスは顧客という概念を表す
Userの検索方法(findById)とかUserの永続化方
法(save)とかは顧客という概念の範疇じゃない
Userクラスは顧客という概念のみに着目したい
- 24. 実践編
こっちのが好き
User user = userRepository.findById(1);
user.modifyAge(100);
userRepository.save(user);
顧客の保存場所から該当顧客を検索し
年齢を変更した後
保存場所へ再度保存する
- 27. 実践編
まとめると
顧客カテゴリ
サービス層
UserModificationServiceクラス
ロジック層
Userクラス
インフラ層
UserRepositoryクラス
こんな感じの世界観をModel層の中にたく
さん作っていく
- 30. まとめ
設計、やってますか？
現実と戦うための
現実世界を整理するための考え方
仕様の背景にある世界を洞察しよう
システムは現実の延長線上にある
概念の名前をコードに取り入れ、表現する
早い段階で実装の詳細に着目しすぎない
関心事を小さく保つ
着目したいものだけに着目するため
