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