Upgrade to Pro — share decks privately, control downloads, hide ads and more …

DDD導入に踏み切れない方へ贈る「2層 + CQS アーキテクチャ(Flyweight DDD)」/Flyweight DDD

DDD導入に踏み切れない方へ贈る「2層 + CQS アーキテクチャ(Flyweight DDD)」/Flyweight DDD

Flyweight DDD
軽量DDDを避けつつ軽量(Flyweight)にDDDを導入するためのアーキテクチャです。

[email protected]

September 05, 2019
Tweet

Other Decks in Programming

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  10. このスライドのターゲット
    (DDDは気になるんだけどね)

    View Slide

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

    View Slide

  12. 2 + CQS
    Architecture
    (Flyweight DDD)

    View Slide

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

    View Slide

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

    View Slide

  15. DDD is 何 ?
    Whatt’s DDD ??

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  19. 軽量DDDとは?

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  30. 軽量DDDとは?
    軽量DDDの問題点は?

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  36. 2層 + CQS アーキテクチャ

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  63. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    という作戦です。

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide