![やり方
手段 ：ホワイトシートと付箋
参加者：チームメンバ全員で作業（大切）
時間 ：１?２時間程度
[手順]
1. ValueObject(単一のデータ)に名前をつける
2. Entity(データ集まり)に名前をつける
3. 状態(ステータス)を見つける
4. ユースケースごとにEntityのライフサイクルを考えてみる](https://image.slidesharecdn.com/biglobeddddevlove20150618-150618145459-lva1-app6891/85/Biglobexddd-dev-love-20150618-23-320.jpg)
![[のれん分け方式]
チームを分けて、
それぞれに人を追加する
変えたいのは、
プロセスではなく考え方
チームの拡大](https://image.slidesharecdn.com/biglobeddddevlove20150618-150618145459-lva1-app6891/85/Biglobexddd-dev-love-20150618-47-320.jpg)
Biglobe×ddd 実践編(dev love 20150618)
- 2. 自己紹介 ? 西 秀和（３３歳） ? 経営管理センター(BMC) 主任 ? ビックローブで勤務 ? ビックローブ光 開発チーム (リードエンジニア)
- 3. 光戦争勃発
- 6. 1. DDDを適用するサービスを決める 2. DDD適用のためのチームを作る 3. 実践する 4. 障害が起きる 5. まとめ 実践編
- 8. DDDの利点って？ ? 変更コストを下げる ? 業務知識をドメイン(コード)に貯め る ? エンジニアの視点をユーザ視点に戻 す
- 14. 滨厂笔业界をとりまく环境
- 15. 2.専用チームを作る
- 16. なぜ専用チーム？ ? 全員で設計する ? プロセスではなく考え方を変え たい ? 既存の业务が邪魔
- 18. 3.実践する
- 20. まずは ドメインモデル を作る
- 23. やり方 手段 ：ホワイトシートと付箋 参加者：チームメンバ全員で作業（大切） 時間 ：１?２時間程度 [手順] 1. ValueObject(単一のデータ)に名前をつける 2. Entity(データ集まり)に名前をつける 3. 状態(ステータス)を見つける 4. ユースケースごとにEntityのライフサイクルを考えてみる
- 24. 636クラス 13テーブル
- 25. ユースケースフロー を考える
- 26. ユースケースフロー図
- 28. データベースを 考える
- 29. 手段 ：ホワイトシートと付箋 参加者：チームメンバ全員で作業（大切） 時間 ：特に決めない 単位 ：Entity単位に設計 ※必要なDB項目は全てこのタイミングで洗い出す やり方
- 30. 設計方針 state(マスタ)テーブル と history(履歴)テーブル ※update中心の考え方 このプロジェクトで設計方針を変更 eventテーブル と 補助的にstate(マスタ)テーブル ※insert中心(イミュータブルデータモデル) 業務を中心に考えると、 event毎にデータが残る方が自然
- 31. スケルトンコードを 書いてみる
- 33. スケルトンコードとは？ ? 中身のない(骨組みだけの)クラスだけのコード ? はじめは、ドメイン層のみ作成 目的は？ ? クラス設計の代わり(クラス図は面倒だった) ? 意外とドメインモデルの修正もある
- 34. 実装してみる
- 35. 1. インフラストラクチャ層 2. Fixture(テストデータ)の準備 3. アプリケーション層 & ドメイン層 4. ユーザインタフェース層 作成順 api (ユースケース) 単位 Entity (業務データ) 単位
- 38. リリースしてみる
- 39. 4.障害が起きる
- 40. リリース日 障害４件
- 45. 5.まとめ
- 51. ご静聴 ありがとう ございました