DDDについて勉強したので5分でまとめる

Slide 1

Slide 1 text

DDDの勉強をしたので5分でまとめる

Slide 2

Slide 2 text

自己紹介吉田です Twitter @strtyuu

Slide 3

Slide 3 text

ドメイン駆動設計とは？ドメインをモデリングしてモデリングしてモデリングし続ける設計手法のこと

Slide 4

Slide 4 text

ドメインとは？アプリケーションが解決したい問題そのもののこと

Slide 5

Slide 5 text

モデリングとは？モデルの振る舞いを定義していく作業のことを指します。

Slide 6

Slide 6 text

モデルとは？ドメインを構成する様々な要素のこと

Slide 7

Slide 7 text

たとえば会議室の予約システムを作りますとなった場合会議室はもちろんモデルになると思いますし予約という概念もモデルになります。

Slide 8

Slide 8 text

モデリングのやり方ドメインエキスパートとドメインについて話し合って話し合いを設計に反映させて設計を元に実装をしてドメインエキスパートとドメインについて話し合って話し合いを設計に反映させて設計を元に実装をしてドメインエキスパートと...

Slide 9

Slide 9 text

以下エンドレス

Slide 10

Slide 10 text

モデルがどんどん更新されてゆく実装は更新されてゆくモデルについていかなければならないつまり、変更に対して柔軟な実装になっていないと、ドメイン駆動設計っていうのは、実現できない

Slide 11

Slide 11 text

柔軟な実装をするためにデザインパターンを駆使して、複雑さに立ち向かう Repository Entity ValueObject Layered Architecture Aggregate 他

Slide 12

Slide 12 text

レイヤードアーキテクチャアプリケーションをいくつかの層に分けてそれぞれの役割を明確に区別すること

Slide 13

Slide 13 text

レイヤー化するメリット層同士の依存関係が最低限に抑えられるので層のインターフェースが変わらなければ、他の層への影響はあまりない（ことが多い）つまり、変更がしやすくなる。

Slide 14

Slide 14 text

たとえば isReservable()) { // 予約不可な場合の処理 } // 登録処理 } } 予約が可能かどうかのロジックがいくら変わろうが、アプリケーション層は変更せずにそのまま使用できる

Slide 15

Slide 15 text

基本的な4つの層プレゼンテーション層アプリケーション層ドメイン層インフラ層

Slide 16

Slide 16 text

プレゼンテーション層アプリケーションの外側と内側の接点最終的にアプリケーションの外側に渡したいデータを出力する役割を持っている

Slide 17

Slide 17 text

アプリケーション層ドメインロジック以外の処理を担当する

Slide 18

Slide 18 text

ドメイン層ドメインのルール・ロジックを全て担当する。ドメイン層以外はドメインロジックを持ってはいけない

Slide 19

Slide 19 text

インフラ層データベースとのやりとりなどを担当する

Slide 20

Slide 20 text

ドメイン層を構成する要素 Domain Service Entity ValueObject Factory

Slide 21

Slide 21 text

ValueObject イミュータブル(不変)なオブジェクト値としてあるべき姿や振る舞いを定義してあげる

Slide 22

Slide 22 text

たとえば会議室の予約に通常の予約の他に「仮予約」や「キャンセル」などのステータスがあった場合、予約のステータスの値には特定の値しか存在してほしくありません。そういったときなどにValueObjectを作ります。

Slide 23

Slide 23 text

Entity ミュータブル(可変)なオブジェクト 1つの1レコードをオブジェクト化するイメージ複数のValueObjectやリレーション先のEntityなどで構成される様々なドメインルールを表現する

Slide 24

Slide 24 text

たとえばキャンセルされた予約は予約済みに戻すことができないというドメインルールがあった場合、以下のような感じで表現出来ます status->isCancel()) { throw new LogicException(); } $this->user_id = $user->getUserId(); $this->status = new Status('Reserved'); } }

Slide 25

Slide 25 text

たとえばこういった書き方をすることによって、ドメインルールと矛盾した処理をアプリケーション層で書くことが不可能になります rsv_repo->findById($id); $user = $this->user_repo->findById($user_id); // 絶対に例外が発生する $canceledRsv->reservedBy($user); $this->rsv_repo->save($reservation); } }

Slide 26

Slide 26 text

Factory Entityを生成する際に複雑な処理が必要な時などに使う

Slide 27

Slide 27 text

Domain Service Entity単体では対応しきれないドメインルールを担当する

Slide 28

Slide 28 text

たとえばユーザーのメールアドレスは重複してはならないというドメインルールがあった場合これは複数のEntityに関わることなので1つのEntityだけでは判断しきれません。そういった処理はDomain Serviceの仕事となります。

Slide 29

Slide 29 text

インフラ層を構成する要素 Aggregate Repository

Slide 30

Slide 30 text

Aggregate ライフサイクルが同じオブジェクトをひとまとめにする「概念」

Slide 31

Slide 31 text

たとえば会議室の予約に、利用者一覧みたいなデータを登録できるとします。利用者の人数は可変なので予約とは別テーブルにすることにします。テーブルは別ですが、新規予約時に予約と一緒に利用者も登録されますし、予約の編集時に利用者も編集されますし、予約の削除時に利用者も削除されるかと思います。また、予約をどうこうする時以外は利用者のデータは変更されなさそうです。こういった場合は予約と利用者は一つの集約と言えます。

Slide 32

Slide 32 text

Repository データベースへのアクセスを提供する役割を持つ。 Aggregateごとに作成して、整合性を保つ。 AggregateのルートになるEntity以外へは直接アクセスさせない。

Slide 33

Slide 33 text

たとえば先ほどの例でいうと予約がAggregateのルートになり、予約Entityからしか利用者のデータには辿れなくします。そうすることによって、Aggregate内の整合性を保ちやすくします。

Slide 34

Slide 34 text

たとえばルートとなるReservationに利用者は10人までしか登録できないというドメインルールを定義します。 users) > 10) { throw new LogicException(); } $this->users[] = $user; } }

Slide 35

Slide 35 text

たとえばそうすると、もちろんReservationEntityを使う限り10人を超えた利用者は登録できなくなります user_repo->getAllUsers(); $reservation = $this->rsv_repo->findById($id); foreach ($users as $user) { // 10 人を越えると必ず例外が発生する $reservation->addUser($user); } $this->rsv_repo->save($reservation); } }

Slide 36

Slide 36 text

たとえばそして、RepositoryはルートEntityしか受け付けないようにすることでドメインルールに適合したデータのみがDBへ書き込まれることが保証されます。

Slide 37

Slide 37 text

まとめデザインパターンを駆使して、変更が容易な設計にしよう！変更を容易にしてモデリングをしまくろう！良いアプリケーション、作ろうぜ！