不味いDDDと美味しいDDD

Slide 1

Slide 1 text

とんこつラーメンは不味い

Slide 2

Slide 2 text

どう思いますか？

Slide 3

Slide 3 text

本当でしょうか？

Slide 4

Slide 4 text

不味いお店もあれば、美味しいお店もある

Slide 5

Slide 5 text

アーキテクチャも同じでは？

Slide 6

Slide 6 text

良いDDDもあれば、悪いDDDもある

Slide 7

Slide 7 text

MVC vs DDD よくある議論

Slide 8

Slide 8 text

同じディレクトリ構成なのかな？

Slide 9

Slide 9 text

なぜかディレクトリ構成は議論されない

Slide 10

Slide 10 text

良いDDDを使って賛成派、悪いDDDを使って反対派

Slide 11

Slide 11 text

良いDDD × 悪いDDD

Slide 12

Slide 12 text

コードを仕様書にする

Slide 13

Slide 13 text

フレームワークの構成ではなくサービスを優先した構成

Slide 14

Slide 14 text

現実世界で考えよう

Slide 15

Slide 15 text

想像してみてください...

Slide 16

Slide 16 text

すべてのプロジェクトの wordが1つのフォルダに入っていたら...。

Slide 17

Slide 17 text

ファイルの種類ごとに管理 PDF Excel Word img ファイル数が少ないと管理で困らない

Slide 18

Slide 18 text

ファイルの種類ごとに管理 PDF Excel Word img 数が多いと目的のファイルが見つけにくい後々、困る

Slide 19

Slide 19 text

担当プロジェクトのファイルを見つけるだけで一苦労ですよね？

Slide 20

Slide 20 text

MVCはこれに近いです

Slide 21

Slide 21 text

最初はいいけど、関連性が見えず保守で苦労をする

Slide 22

Slide 22 text

作った本人しかわからない

Slide 23

Slide 23 text

これがMVCの問題です

Slide 24

Slide 24 text

なので、どの会社も....

Slide 25

Slide 25 text

フォルダで整理しています

Slide 26

Slide 26 text

PDF Excel Word img 実際に会社はどう整理している？

Slide 27

Slide 27 text

ファイルの種類ごとに管理提案書仕様書ワイヤーアイコンプロジェクトごとにファイル管理するプロジェクトA 提案書仕様書ワイヤーアイコンプロジェクトB 用途ごとにまとめる用途ごとにまとめるカプセル化 => 影響範囲が明確。必要分だけ確認カプセル化

Slide 28

Slide 28 text

エンジニア的にいうとモジュールで分けます

Slide 29

Slide 29 text

影響範囲が制限されているだから、変更しやすい

Slide 30

Slide 30 text

ファイルの種類ごとに管理仕様書責務が分かれている仕様書の見直しが必要な場合、仕様書ディレクトリを確認すればいい。

Slide 31

Slide 31 text

責務が分かれていると必要な箇所だけ編集できる

Slide 32

Slide 32 text

何が無関係か明確である

Slide 33

Slide 33 text

新規メンバーも着手しやすい

Slide 34

Slide 34 text

Slide 35

Slide 35 text

大多数の会社で同じですよね？

Slide 36

Slide 36 text

では、コードはどうですか？

Slide 37

Slide 37 text

ファイルの種類ごとに管理提案書仕様書ワイヤーアイコン MVCとDDDもこれと同じ DDD アーキテクチャ構成 => 複雑になると混乱 MVC PDF Excel Word img MVC => 担当箇所が明確

Slide 38

Slide 38 text

つまり、フレームワークの機能ではなく、サービスの機能に合わせるべき。

Slide 39

Slide 39 text

機能の仕様がわかりやすい

Slide 40

Slide 40 text

別にそこまでしなくてもいいんじゃない？

Slide 41

Slide 41 text

問題です。

Slide 42

Slide 42 text

あなたのプロジェクトの仕様はどこにまとまっていますか？（※コードにおいて）

Slide 43

Slide 43 text

パッと答えられなかった場合は、新規メンバーも困る可能性が高い

Slide 44

Slide 44 text

DDDでは、 Domain層に仕様を書く

Slide 45

Slide 45 text

Presentation層 Application層 Domain層 Infrastructure DDDの構成 Controller, Request, ViewModel, Resource ApplicationService, Command DomainService, DomainModel, ValueObject Repository, Factory 画面などに関わる部分 CRUDなど機械的に必要な処理仕様に関すること AWSやDBなど機械に依存する箇所

Slide 46

Slide 46 text

Controller Serivce Repository

Slide 47

Slide 47 text

Controller ApplicationSerivce DomainSerivce Repository サービス層を二つにわける

Slide 48

Slide 48 text

ApplicationSerivce DomainSerivce プログラムに必須仕様に関すること CRUD publish()

Slide 49

Slide 49 text

アプリの仕様は DomainServiceをまずみる

Slide 50

Slide 50 text

Domain層 DomainService：サービスの仕様 DomainModel：オブジェクトの仕様 ValueObject：カラムの仕様省略

Slide 51

Slide 51 text

注意点 Domain層は必須ではない。複雑な仕様になったら、つくる

Slide 52

Slide 52 text

レイヤー重視型モジュール重視型

Slide 53

Slide 53 text

レイヤー重視型レイヤーごとに機能のディレクトリが存在する

Slide 54

Slide 54 text

機能単位にモジュール分けモジュール内にレイヤードアーキテクチャを採用するモジュール重視型