Tweet
Tweet

Slide 1

Slide 1 text

DDD導入に踏み切れない方へ贈る 2層 + CQS アーキテクチャ (Flyweight DDD) 軽量DDDにならないための軽量なDDDのすゝめ

Slide 2

Slide 2 text

自己紹介 hiro@miraito PHPer 株式会社ミライトデザイン CEO 美容室サブスクリプションサービスMEZON 株式会社 Jocy CTO 好き : OOP, DDD, Architecture, Agile, Team Build 勉強会 : PHPer 向けワーキンググループぺちオブ主催 Object Oriented Conference主催 Twitter : @hirodragon112

Slide 3

Slide 3 text

今日話したいこと 1. このスライドのターゲット 2. DDD is 何 ？ 3. 軽量DDDとは？ 4. 2層 + CQS アーキテクチャ

Slide 4

Slide 4 text

今日話したいこと 1. このスライドのターゲット 2. DDD is 何 ？ 3. 軽量DDDとは？ 4. 2層 + CQS アーキテクチャ

Slide 5

Slide 5 text

このスライドのターゲット このような方いませんでしょうか？

Slide 6

Slide 6 text

このスライドのターゲット DDD良さそう。 DDD面白そう。 DDDに可能性を感じる。

Slide 7

Slide 7 text

このスライドのターゲット でも、、、

Slide 8

Slide 8 text

このスライドのターゲット いきなり導入する のはちょっと勇気 がいる・・・ もし途中でうまく いかなかったらど うしよう・・・

Slide 9

Slide 9 text

このスライドのターゲット いつもどおりフ レームワークを ベースに開発す るか

Slide 10

Slide 10 text

このスライドのターゲット （DDDは気になるんだけどね）

Slide 11

Slide 11 text

このスライドのターゲット 今回はこんな方に提案したい アーキテクチャを紹介したいと思います。

Slide 12

Slide 12 text

2 + CQS Architecture (Flyweight DDD)

Slide 13

Slide 13 text

このスライドのターゲット ・ Command … 書込み系。 副作用を持つ ・ Query … 参照系。返り値を返す

Slide 14

Slide 14 text

今日話したいこと 1. このスライドのターゲット 2. DDD is 何 ？ 3. 軽量DDDとは？ 4. 2層 + CQS アーキテクチャ

Slide 15

Slide 15 text

DDD is 何 ？ Whatt’s DDD ??

Slide 16

Slide 16 text

DDD is 何 ？ 端的に言うと 「ドメインを中心に据えた設計」です。

Slide 17

Slide 17 text

DDD is 何 ？ 詳細は他の方がきっと語られていると思うので 本スライドでは割愛します。 （時間の都合上申し訳ないです）

Slide 18

Slide 18 text

今日話したいこと 1. このスライドのターゲット 2. DDD is 何 ？ 3. 軽量DDDとは？ 4. 2層 + CQS アーキテクチャ

Slide 19

Slide 19 text

軽量DDDとは？

Slide 20

Slide 20 text

軽量DDDとは？ 今回のテーマは 「軽量DDDにならないための軽量なDDD」 です。

Slide 21

Slide 21 text

軽量DDDとは？ ・ そもそも軽量DDDとは？ ・ あまり良くはないと言われる理由は？

Slide 22

Slide 22 text

軽量DDDとは？ DDDは大きく分けて ・ 戦略的設計 ・ 戦術的設計 の2工程

Slide 23

Slide 23 text

軽量DDDとは？ 戦略的設計 対象ドメインを理解し、システムに落とし込む為 の枠組み作り ユビキタス言語策定、ドメインモデリング（サブドメイン、境界コンテキスト） コンテキストマップ作成、等が戦略的設計に分類されます。

Slide 24

Slide 24 text

軽量DDDとは？ 戦術的設計 具体的な実装パターン。 戦略設計により洗い出されたドメイン知識や ルールを具体的にコードに落とし込む為の手法 EntityやValue Object、Repository, Factory, 集約等々の実装パターンが戦術的設 計に分類されます。

Slide 25

Slide 25 text

軽量DDDとは？ よく聞くDDDの説明 「対象ドメインをドメインエキスパートと共通の言 語となるユビキタス言語で語り、モデリングし、 そのモデリングがそのまま実装に落とし込まれ る」

Slide 26

Slide 26 text

軽量DDDとは？ この説明は戦略的設計と戦術的設計が折り重 なって初めて実現できます。

Slide 27

Slide 27 text

軽量DDDとは？ それでは軽量DDDと呼ばれるものはなんでしょ うか？

Slide 28

Slide 28 text

軽量DDDとは？ それは、いわゆる戦術的設計のみを取り入れ た設計をさします。

Slide 29

Slide 29 text

軽量DDDとは？ Aggregate root があり集約がEntityやValue Object により構成されていて Repository を使用 して永続化と再構築を行う・・・・というような、 DDDの戦術面（実装面）のみにフォーカスをあて た状態です。

Slide 30

Slide 30 text

軽量DDDとは？ 軽量DDDの問題点は？

Slide 31

Slide 31 text

軽量DDDとは？ 冒頭で触れましたがDDDとは 「ドメインを中心に据えた設計」 です

Slide 32

Slide 32 text

軽量DDDとは？ あくまで中心に据えて守りたい（集中したい）コ アがあるからこそ（目的）、そしてそれらを具体 的な技術的関心事から分離する方法（手段）為 に、戦術的な設計が必要となります。

Slide 33

Slide 33 text

軽量DDDとは？ つまり、ともすれば軽量DDDとは「目的」のない 「手段」となってしまう可能性があります。 だから軽量DDDにならないようにしましょうね、 みたいな事がよく言われているんですね。

Slide 34

Slide 34 text

今日話したいこと 1. このスライドのターゲット 2. DDD is 何 ？ 3. 軽量DDDとは？ 4. 2層 + CQS アーキテクチャ

Slide 35

Slide 35 text

2層 + CQS アーキテクチャ ようやく本題にはいりますね。

Slide 36

Slide 36 text

2層 + CQS アーキテクチャ

Slide 37

Slide 37 text

2層 + CQS アーキテクチャ:概要 今日お話する内容は正攻法のDDDの話しではありません。 冒頭でも説明した通り、DDD導入を検討したいけど少し迷い がある。 という方に向けた少し亜流の手法を紹介したいと思います

Slide 38

Slide 38 text

2層 + CQS アーキテクチャ:概要 さらに具体的に言えば、部分的にでも良いから DDDを取り入れていく事で今後本格導入する為 の知見を得て行こう！ というのが目的となります。

Slide 39

Slide 39 text

2層 + CQS アーキテクチャ:概要 ただし、、、

Slide 40

Slide 40 text

2層 + CQS アーキテクチャ:概要 「部分的に導入」と言っても軽量DDDはあんま 良くないんでしょ・・・？

Slide 41

Slide 41 text

2層 + CQS アーキテクチャ:概要 軽量DDDにならない為の軽量なDDD！！

Slide 42

Slide 42 text

2層 + CQS アーキテクチャ まず今から、今回立てた 「軽量DDDにならないための 2つの作戦」 を紹介します

Slide 43

Slide 43 text

2層 + CQS アーキテクチャ ① 戦略的設計をしっかりやる。 ② フレームワークの利点を可能な範囲で残す

Slide 44

Slide 44 text

2層 + CQS アーキテクチャ 一つずつ説明していきたいと思います

Slide 45

Slide 45 text

2層 + CQS アーキテクチャ:概要 軽量DDDにならないための作戦 ① 戦略的設計をしっかりやる。

Slide 46

Slide 46 text

2層 + CQS アーキテクチャ:概要 戦略設計を省略してはどうやっても軽量DDDに なってしまいます。 ここはもうつべこべ言わずやるしかないです。 やりましょう。やってみせましょう。やりとげま しょう！

Slide 47

Slide 47 text

2層 + CQS アーキテクチャ:概要 でもじゃあ、軽量化っていったいどこが軽量化 なの？

Slide 48

Slide 48 text

2層 + CQS アーキテクチャ:概要 戦術面を軽量化します！

Slide 49

Slide 49 text

2層 + CQS アーキテクチャ:概要 以上。

Slide 50

Slide 50 text

2層 + CQS アーキテクチャ:詳細

Slide 51

Slide 51 text

2層 + CQS アーキテクチャ:概要 軽量DDDにならないための作戦 ②

Slide 52

Slide 52 text

2層 + CQS アーキテクチャ:概要 普段PHPでシステム開発をしているのですが、 PHPerの中でも昨今DDDへの関心が非常に高 いと感じています。

Slide 53

Slide 53 text

2層 + CQS アーキテクチャ:概要 ただ、実際に導入してみた、チャレンジしてみた、 というプロダクトは増えているのか？というと肌 感としてはあまり増えていないように感じます。

Slide 54

Slide 54 text

2層 + CQS アーキテクチャ:概要 その背景に何があるかと言うと - フレームワークの便利さを捨てきれない - 慣れない手法を取る事へのリスクを感じる

Slide 55

Slide 55 text

2層 + CQS アーキテクチャ:概要 この2点が大きいのではと個人的には考えてい ます。

Slide 56

Slide 56 text

2層 + CQS アーキテクチャ:概要 軽量DDDにならないための作戦 ② フレームワークの利点を可能な限り残す

Slide 57

Slide 57 text

2層 + CQS アーキテクチャ:概要 これが亜流と書いた理由になります。 一般的にはFWに依存などあってはダメですよ ね。

Slide 58

Slide 58 text

2層 + CQS アーキテクチャ:概要 これは不慣れな手法にトライする際に余分な工 数が発生するので、慣れた手法を残す事で戦 略面にも時間を避けるようにしようというのが目 的です。

Slide 59

Slide 59 text

2層 + CQS アーキテクチャ:概要 また、PHPに限って言いますとLaravelでよく使用 されるORMのEloquentが非常に便利だから離 れられないという方もいますが、そういった方へ の解決の一つともなりえます。

Slide 60

Slide 60 text

2層 + CQS アーキテクチャ:概要 以上、2つの作戦を実現しつつDDDとしてのメ リットを守る一つのキーワードがあります。

Slide 61

Slide 61 text

2層 + CQS アーキテクチャ:概要 CQS

Slide 62

Slide 62 text

2層 + CQS アーキテクチャ:概要 CQSについては後ほど説明したいと思いますが、 まずは一般的なDDDのアーキテクチャを確認し たいと思います。

Slide 63

Slide 63 text

No content

Slide 64

Slide 64 text

2層 + CQS アーキテクチャ:概要 拡大した図です。 よくある UseCase(Application Service) がDomain層にあるEntityやDomain Serviceを操作して、最終的に Repositoryにより永続化、再構築を行 います。 よくある一般的な設計だと思います。 MVCのMはInfrastructure層、V, C は Presentation層にて使用されています。

Slide 65

Slide 65 text

2層 + CQS アーキテクチャ:概要 拡大した図です。 よくある UseCase(Application Service) がDomain層にあるEntityやDomain Serviceを操作して、最終的に Repositoryにより永続化、再構築を行 います。 よくある一般的な設計だと思います。 MVCのMはInfrastructure層、V, C は Presentation層にて使用されています。

Slide 66

Slide 66 text

2層 + CQS アーキテクチャ:概要 拡大した図です。 よくある UseCase(Application Service) がDomain層にあるEntityやDomain Serviceを操作して、最終的に Repositoryにより永続化、再構築を行 います。 よくある一般的な設計だと思います。 MVCのMはInfrastructure層、V, C は Presentation層にて使用されています。

Slide 67

Slide 67 text

2層 + CQS アーキテクチャ:概要 ここに先程立てた作戦を取り入れる事でDDDの 導入を試みつつもFWの利便性を残して開発に 余裕をもたせるのが今回の目的です。

Slide 68

Slide 68 text

2層 + CQS アーキテクチャ:概要 では、どのように作戦を取り入れるというか？ ここで出てくるのが先程のCQSです。

Slide 69

Slide 69 text

カウボーイの声 LB 「そう言えばCQSとCQRSって何が違うんだい？」 AJ 「そりゃまあRが違うんだろRが。きっと水だろうな」 LB 「なるほど。お前は相変わらず畑に水をまくんだな！」 CQSと近いCQRSという言葉も耳馴染みかと思います。 明確に定義された言葉を見つけられなかったのですが、CQRSはいわゆる「責務」 まで分離された状態を表します。 また、「S」に関しても Separation と Segregation と言葉が違います。 詳細はおいておきますが、ここではデータモデルがCommandとQueryで完全に 独立しているかどうかを堺に言葉を使い分けています。（本当はもっと明確な違 いがあると思いますが）

Slide 70

Slide 70 text

2層 + CQS アーキテクチャ:概要 CQS(Command Query Separation) とは 端的に言うとCommand(書き込み処理)と Query(読み込み処理)を分離して扱おう という手法です。

Slide 71

Slide 71 text

2層 + CQS アーキテクチャ:概要 今回はこの考え方を取り入れて、立てた作戦を 実行したいと思います。 どういうことかと言うと、、、

Slide 72

Slide 72 text

2層 + CQS アーキテクチャ:概要 CQSによりCommandとQueryを分割した上で 「Command部分は戦術的設計を導入」し、 「Query部分はFWに依存した設計」にしてしまお う という作戦です。

Slide 73

Slide 73 text

2層 + CQS アーキテクチャ:概要 それでは具体的にCommandとQuery用のそれ ぞれのアーキテクチャを見ていきたいと思いま す。

Slide 74

Slide 74 text

Command時 基本的に通常のDDDと変 わらない。 Command操作は副作用を 伴いシステムの状態を変 更する。 DDDの集約設計などドメイ ン固有のルールやロジック を中心に据えた設計にて しっかりと対象ドメインの活 動をシステムに落とし込む。 トランザクション管理もこち らのみ

Slide 75

Slide 75 text

具体的に見るとわかります が、Command時は一般的 なアーキテクチャを採用し ます。 DDDをやる以上、Domain の知識を明確に分離して 対象を意図的に表現する 必要があります。 集約によるライフサイクル の管理やValue Object に よって値の表現を的確に 行います。

Slide 76

Slide 76 text

Query時 今回の作戦のミソとなる。 参照系の操作を分離し、こ こに関してはがっつりとFW に依存した設計とする。 副作用を伴わない参照系 操作に限定する事によりド メインルールを壊す心配が ない。 また、FWのORMの便利機 能等をそのまま使用でき 開発スピードも極限まで落 とさずに済む。 例えば参照したModelをそ のままViewに渡して使用 するとかも問題ない。

Slide 77

Slide 77 text

Query時 いわゆる参照系の際は非 常にシンプルです。 Repository によるDomain Object の再構築もしませ ん。 DBを直接ORMを使用して 参照します。 この辺はDDD導入以前の 普段どおりの開発が行な えます。

Slide 78

Slide 78 text

Query時 また、Presenter が直接 ORMのModelを使用してい ます。 画面の描画用にこのまま Viewに渡してしまっても良 いです。 Pagenator 等 ORMの便利 機能をそのままViewでも 使ってしまいましょう。 もうViewModelに詰め変え る日々も、ValueObjectをUI で使用して良いかも悩む 必要はありません。 FWサイコー

Slide 79

Slide 79 text

2層 + CQS アーキテクチャ:概要 メリット Repository肥大化など導入時にありがちな問題を防げる 完全導入によりも導入コストを抑える事ができ、本来重要な戦略的設計に工数 をかけられる 最悪Command側を直せばいつもの開発に戻れる。

Slide 80

Slide 80 text

2層 + CQS アーキテクチャ:概要 デメリット DDDとFWどちらも中途半端になる 当然ながら参照処理には依存が発生しまくる DB直接依存なので参照系の単体テストが書き辛くなる 参照もドメイン知識な場合適用できない

Slide 81

Slide 81 text

まとめ 今回紹介した 「Flyweight DDD 」 は、あくまで亜流、かつ最適解とはならないため もし参考にされる際は自己責任でお願いいたします。 また、知見がまだまだ足りていない為試しながらフィードバックを受けながら 改善していきたいと思います。

Slide 82

Slide 82 text

まとめ YYPHPにてフルバージョンを発表した所 わかりやすい名前があると良いかもという事で @suin さんに命名して頂いたのでこのアーキテクチャを FWDDD (Flyweight DDD) と命名したいと思います。