DDD x CQRS - 更新系と参照系で異なるORMを併用して上手くいった話

参考資料：http://little-hands.hatenablog.com/entry/jjug2017fall

社内新規プロダクトでDDD, CQRSの思想をベースとしたアーキテクチャを構築し、コマンド(更新系処理)ではSpring Data JPA(Hibernate)を、クエリ(参照系処理)ではjOOQを採用しました。
結果としてそれぞれのORMの良いところを生かした組み合わせのアーキテクチャが構築できたので、その経緯と得られた知見についてお話ししたいと思います。
以下のようなトピックを考えています。

・CQRSの定義とメリットデメリット
・DDD,CQRSを検討するにあたってのORMの選定ポイント
・構築したアーキテクチャ

CQRSはDDDと切り分けて単独でも適用することができるので、DDDについてご存知ない方もご覧いただけます。日本語の文献は意外と少ないので、この辺りの分野に興味がある人の参考になれば幸いです。

Transcript

1. JJUG CCC 2017 fall DDD x CQRS - 更新系と参照系で異なるORMを併用して上手くいった話 2017/11/18 株式会社ビズリーチ 松岡 幸一郎
2. • 松岡 幸一郎 • 株式会社ビズリーチ • @little_hand_s • #ccc_m4 発表者紹介
3. 最近こんなCMしてる会社です 自己紹介
4. Java 技術遍歴 SIer時代
5. Java 技術遍歴 SIer時代 Excel
6. 技術遍歴 Excelはもういい
7. Java 技術遍歴 SIer時代 Excel Spring Boot DDD・CQRS Vue.js 現職
8. DDD x CQRS 更新系と参照系で 異なるORMを併用して 上手くいった話 テーマ
9. DDD x CQRS 更新系と参照系で 異なるORMを併用して 上手くいった話 テーマ
10. ブログで細々とDDD布教中 http://little-hands.hatenablog.com/
11. なんですが
12. DDD x CQRS 更新系と参照系で 異なるORMを併用して 上手くいった話 テーマ ←今日のメイン
13. DDDとは • Domain Driven Design(ドメイン駆動設計)の略称 • ドメインとは ◦ 「アプリケーションの中心となる業務領域」のこと • 原則 ◦ ドメインとドメインロジックを中心に設計する ( ≠ データモデル中心) ◦ 複雑なロジックをドメインモデルに寄せる (オブジェクト志向に則る) ◦ ドメインエキスパート(業務の専門家)と継続的にコミュニケーションし、モデルを改善し続ける • メリット ◦ ステークホルダー間のコミュニケーションが容易になる ◦ ソースの可読性、変更容易性、メンテナンス性が高まる • EricEvansによる定義
14. DDDとは • Domain Driven Design(ドメイン駆動設計)の略称 • ドメインとは ◦ 「アプリケーションの中心となる業務領域」のこと • 原則 ◦ ドメインとドメインロジックを中心に設計する ( ≠ データモデル中心) ◦ 複雑なロジックをドメインモデルに寄せる (オブジェクト志向に則る) ◦ ドメインエキスパート(業務の専門家)と継続的にコミュニケーションし、モデルを改善し続ける • メリット ◦ ステークホルダー間のコミュニケーションが容易になる ◦ ソースの可読性、変更容易性、メンテナンス性が高まる • EricEvansによる定義 略
15. DDD x CQRS 更新系と参照系で 異なるORMを併用して 上手くいった話 テーマ
16. まず、 CQRSに関する誤解を解きたい テーマ
17. まず、 CQRSに関する誤解を解きたい テーマ (※個人の見解です)
18. CQRSは イベントソーシングと セットで行う必要がある テーマ
19. CQRSは イベントソーシングと セットで行う必要がある テーマ
20. CQRSは イベントソーシングと セットで行う必要がある テーマ CQRSは単独で適用できます
21. CQRSとは
22. • CQRSとは ◦ Command Query Responsibility Segregation コマンドクエリ責務分離 ◦ 書き込み用のモデルと読み込み用のモデルを分ける設計パターン CQRSとは
23. CQRSの提唱者 • Greg Young ◦ DDD + CQRS + イベントソーシングを推している そのため、CQRSとイベントソーシングがセットで語られがち →　本質的には別のもの
24. • なぜモデルを分ける必要があるのか？ • モデルを分けるとはどういうことなのか？ → 背景から説明します CQRS背景
25. • 一般的なシステムでは、書き込みと読み込みの両方が、 単一のデータストアで同じモデルを使用する • テーブルに対応したオブジェクトがあり、それを使用してCRUD操作する CQRS背景 DB Data Model User Interface Application IF IF
26. • システムが大きくなるほど、 ◦ 書き込み：制御は複雑になっていく ◦ 読み込み：複数テーブルの情報をまとめて加工する必要性が高まっていく → 一つのモデルに関する処理がどんどん複雑になっていく CQRSが必要な背景
27. • システムが大きくなるほど、 ◦ 書き込み：制御は複雑になっていく ◦ 読み込み：複数テーブルの情報をまとめて加工する必要性が高まっていく → 一つのモデルに関する処理がどんどん複雑になっていく CQRSが必要な背景 • そもそも、書き込み・読み込みで要件が大きく異なる ◦ 整合性か、速度か ◦ オブジェクトの形か、結合や集計した形か(モデル表現の違い) ◦ トラフィック数は圧倒的に読み込み処理が多い ◦ パフォーマンス要件は異なることが多い 　　→ どこかにしわ寄せ、妥協が発生する
28. CQRSのステップ
29. CQRSのステップ • 段階的CQRS a. 書き込み / 読み込みモデルを分離する b. 書き込み / 読み込みデータストアを分離する c. イベントソーシングと統合する 　→ 要件を見極めてどうするか判断すればよい
30. CQRS - 1.単一物理データストアモデル • 書き込みと読み込みのモデルを別物として用意する DB Data Model User Interface Application IF IF
31. CQRS - 1.単一物理データストアモデル • 書き込みと読み込みのモデルを別物として用意する DB Data Model User Interface Application IF IF DB User Interface IF IF Write Model Read Model
32. CQRS - 1.単一物理データストアモデル • 書き込みと読み込みのモデルを別物として用意する • 書き込みモデル： テーブル毎に対応したエンティティ等 • 読み込みモデル： テーブルをJoinした結果、SQL viewの取得結果1行などを1モデルとする 　→ それぞれ適したモデルを扱えるので、処理効率が良い書き方ができる 　　コードがシンプルになる DB Data Model User Interface Application IF IF DB User Interface IF IF Write Model Read Model
33. CQRS - 2.複数物理データストアモデル • 書き込みと読み込みのデータストアを物理的に分離する DB User Interface IF IF Write Model Read Model
34. CQRS - 2.複数物理データストアモデル • 書き込みと読み込みのデータストアを物理的に分離する DB User Interface IF IF Write Model Read Model Write Data Store Read Data Store User Interface IF IF Write Model Read Model
35. CQRS - 2.複数物理データストアモデル • 書き込みと読み込みのデータストアを物理的に分離する • Read Data Store ◦ シンプルなのはread-onlyのレプリカ ◦ 全く別の機構を選択することも可能 (Readをelastic searchにするなど) 　→ 参照/更新のストア分離により、それぞれの負荷に合わせたスケーリングが可能 　　異なるアーキテクチャのデータストアを利用可能 DB User Interface IF IF Write Model Read Model Write Data Store Read Data Store User Interface IF IF Write Model Read Model
36. • すべてのアクションを「イベント」として記録する設計パターン 既存のデータのupdateは一切しない ◦ Writeモデルは「イベント」として記録される ◦ Readモデルはそこから特定の形に変形される MaterializedViewや物理的なデータを別途生成する、など CQRS - 3.イベントソーシング (@little_hand_s から参考資料たどれます「イベントソーシングの参考資料」 )
37. Write/Readで ORMを分ける
38. 分離のメリット・デメリット メリット デメリット 1.モデル分離 処理効率が良い書き方ができる コードがシンプルになる readモデルにwriteモデルの制約を 効かせられなくなる 2.データソース 分離 Read / Writeを分離してスケールさせること ができる 設計の幅が広がる データ同期の仕組構築 /メンテコストが必要 3.イベント ソーシング データ追跡しやすい ミューテーション排除によるバグ抑止 インピーダンスミスマッチとの決別 導入難易度がが一気に上がる 導入・教育コストが高い
39. 分離のメリット・デメリット メリット デメリット 1.モデル分離 処理効率が良い書き方ができる コードがシンプルになる readモデルにwriteモデルの制約を 効かせられなくなる 2.データソース 分離 Read / Writeを分離してスケールさせること ができる 設計の幅が広がる データ同期の仕組構築 /メンテコストが必要 3.イベント ソーシング データ追跡しやすい ミューテーション排除によるバグ抑止 インピーダンスミスマッチとの決別 導入難易度がが一気に上がる 導入・教育コストが高い → ORMも適正に合わせて使い分ければ、このメリットをより大きくできるのではないか？
40. CQRSのオプション 各オプションは要件に応じて好きに組み合わせて良い 単一物理ストア 複数物理ストア データストア Read / Write 異なるモデル Read / Write 同じモデル モデル × しない する イベント ソーシング × 単一ORM 複数ORM ORM ×
41. CQRSのオプション 各オプションは要件に応じて好きに組み合わせて良い 単一物理ストア 複数物理ストア データストア Read / Write 異なるモデル Read / Write 同じモデル モデル × しない する イベント ソーシング × → メリット/デメリット、コストを考慮し、今回はこのような構成を選択 単一ORM 複数ORM ORM ×
42. Write/Read ORMの要件 • Write Model ORM ◦ オブジェクト志向でモデルに振る舞いをもたせたい ・DDDの思想を反映 ◦ テーブルに対応したオブジェクト
43. Write/Read ORMの要件 • Write Model ORM ◦ オブジェクト志向でモデルに振る舞いをもたせたい ・DDDの思想を反映 ◦ テーブルに対応したオブジェクト • Read Model ORM ◦ 複数テーブルをjoinしたり、集計したりしたい ◦ 効率の良いクエリが書きたい ◦ 実行されるクエリを制御したい
44. Write/Read ORMの要件 • Write Model ORM ◦ オブジェクト志向でモデルに振る舞いをもたせたい ・DDDの思想を反映 ◦ テーブルに対応したオブジェクト • Read Model ORM ◦ 複数テーブルをjoinしたり、集計したりしたい ◦ 効率の良いクエリが書きたい ◦ 実行されるクエリを制御したい 　→ この要件に合うようにORMを選定する
45. ORMのパターン 中心 SQLロジックの組み込み方法 代表的プロダクト オブジェクト 中心 オブジェクトリレーショナルマッピングを通じ てJavaに組み込む Hibernate、(ActiveRecord) SQL中心 Java外 - XMLなどの設定ファイル MyBatis、SQL view、 ベンダー特有のストアドプロシージャ Java内 - String文字列 JDBC、JPAネイティブクエリ Java内 - 独自DSL jOOQ、JPQL
46. ORMのパターン 中心 SQLロジックの組み込み方法 代表的プロダクト オブジェクト 中心 オブジェクトリレーショナルマッピングを通じ てJavaに組み込む Hibernate、(ActiveRecord) SQL中心 Java外 - XMLなどの設定ファイル MyBatis、SQL view、 ベンダー特有のストアドプロシージャ Java内 - String文字列 JDBC、JPAネイティブクエリ Java内 - 独自DSL jOOQ、JPQL 　→ 先述の要件を踏まえ、3つのORMでメリット/デメリット検討
47. jOOQとは • DBスキーマからDBアクセス用オブジェクト生成 • DSL中心でクエリビルド、実行できるORM • かなりSQLに近い書き方、かつタイプセーフにSQLが書ける
48. メリット デメリット Hibernate (Spring Data JPA) モデルに振る舞いを持たせやすい SpringDataJPAがDDDを想定した仕様 仕様の理解しにくさ、キャッシュなどのトラブ ル、想定外の挙動　etc.. MyBatis SQLを直接かけるのでシンプル、安心 SQLがテキスト記述、 XMLに設定を書くのは今時結構辛い jOOQ タイプセーフなDSLで書きやすい、 読みやすい オブジェクトリレーションの表現に 制限あり ORM選定
49. メリット デメリット Hibernate (Spring Data JPA) モデルに振る舞いを持たせやすい SpringDataJPAがDDDを想定した仕様 仕様の理解しにくさ、キャッシュなどのトラブ ル、想定外の挙動　etc.. MyBatis SQLを直接かけるのでシンプル、安心 SQLがテキスト記述、 XMLに設定を書くのは今時結構辛い jOOQ タイプセーフなDSLで書きやすい、 読みやすい オブジェクトリレーションの表現に 制限あり ORM選定 →Writer Model ORMにHibernate、Read Model ORMにjOOQを採用
50. CQRSを適用するための アーキテクチャ
51. • 一般的な3層アーキテクチャの問題 ◦ Write/Readのモデル使用範囲を明確に分けられない ◦ BusinessLogic層がFatになりやすい アーキテクチャ Business Logic Data User Interface Infrastructure
52. • 業務ロジックをドメイン層に凝集する • アプリケーションサービス層はドメイン層が許可した操作を必要に応じて呼ぶ • この辺りはDDDの思想に基づいた設計 アーキテクチャ Business Logic Data User Interface Infrastructure Application Service Domain Model User Interface Infrastructure (@little_hand_s から参考資料たどれます 「ドメイン駆動 + オニオンアーキテクチャ概略」 )
53. interface アーキテクチャ Application Service Domain Model User Interface Infrastructure Application Service Domain Model User Interface Infrastructure 実装クラス • ドメイン層をPOJOにするために依存関係を逆転する • ドメイン層が公開したIFに対してインフラ層が実装する設計
54. • ドメイン層をWrite Model (ドメインモデル)とRead Modelに分割する • インフラ層の実装クラスをWriteとReadで異なるORMで実装する アーキテクチャ Application Service Domain Model Query Model User Interface Infrastructure Application Service Domain Model User Interface Infrastructure interface 実装クラス
55. アーキテクチャ Application Service Domain Model Query Model User Interface Infrastructure <<interface>> Repository Entity Repository Impl <<interface>> Query Serivce DTO Query Serivce Impl
56. Spring Data JPA アーキテクチャ Application Service Domain Model Query Model User Interface Infrastructure <<interface>> Repository Entity Repository Impl <<interface>> Query Serivce DTO Query Serivce Impl Hibernate Hibernate(アノテーションだけ)
57. Spring Data JPA アーキテクチャ Application Service Domain Model Query Model User Interface Infrastructure <<interface>> Repository Entity Repository Impl <<interface>> Query Serivce DTO Query Serivce Impl jOOQ Hibernate Hibernate(アノテーションだけ)
58. サンプルコード
59. サンプルコード Task タスクID タスク名 ステータス User ユーザーID ユーザー名 作成者 担当者 • シンプルなタスク管理アプリケーションを想定 • タスクの制約 ◦ 作成時の制約 ▪ 「作成者」と「担当者」として実在のユーザーを持つ ▪ 常に「未完了」状態で作成 ◦ 変更時の制約 ▪ 名前は変更できない ▪ 完了/未完了の制御だけできる
60. アーキテクチャ Application Service Domain Model Query Model User Interface Infrastructure <<interface>> Repository Entity Repository Impl <<interface>> Query Serivce DTO Query Serivce Impl Hibernate(アノテーションだけ)
61. サンプルコード Domain Model(entity, repository) Entity Repository
62. ポイント ①entityが保持する値はUserのIdでLong型だが、 引数をUserにすることでTypeSafeになる ②必ず"未完了"の状態でインスタンス生成、 　という制約をコンストラクタで表現 ③ステータス更新用のメソッドは公開されているが、 nameは更新用メソッドを公開しないことにより 「名前を変更できない」という制約を表現 ① ② ③ コンストラクタと公開メソッドで制約を表現 コンストラクタ 状態遷移用メソッド (@little_hand_s から参考資料たどれます 「モデルでドメイン知識を表現するとは何か」 )
63. サンプルコード Application Service ApplicationService(新規作成) ApplicationServiceの引数 ApplicationServiceの戻り値
64. サンプルコード Application Service ApplicationService(更新)
65. アーキテクチャ Application Service Domain Model Query Model User Interface Infrastructure <<interface>> Repository Entity Repository Impl <<interface>> Query Serivce DTO Query Serivce Impl
66. ポイント ・POJOで引数と戻り値の関係だけ定義 →「ライブラリ何使うかは任せるけど、 この条件で指定したらこういう形で返してね」 という宣言をしている サンプルコード queryService クエリモデルのサービス IF 引数
67. アーキテクチャ Application Service Domain Model Query Model User Interface Infrastructure <<interface>> Repository Entity Repository Impl <<interface>> Query Serivce DTO Query Serivce Impl jOOQ
68. サンプルコード queryServiceImpl その他のクエリ部分 ①クエリライクにJavaコードでselect, from, join条件を書いている ②resultをfetch後に戻り値の方に mapしたものをreturnしている ③条件指定の方法は次のページ ① ② ③
69. ・引数オブジェクトの値をjOOQのConditionオブジェクトにマッピング ・引数オブジェクトのパラメータを取得するメソッドを Optionalで返せば、 　値があるときだけ条件指定、ということも可能 ・引数のパラメータを増やせば検索の拡張も簡単 サンプルコード queryServiceImpl 条件指定部分
70. Spring Data JPA アーキテクチャ Application Service Domain Model Query Model User Interface Infrastructure <<interface>> Repository Entity Repository Impl <<interface>> Query Serivce DTO Query Serivce Impl jOOQ Hibernate Hibernate(アノテーションだけ)
71. 導入結果
72. 導入結果 • 実際どうだった？
73. 導入結果 • 実際どうだった？ →かなり使い勝手が良いです！！
74. 導入結果 • 実際どうだった？ →かなり使い勝手が良いです！！ • Read Model ◦ Hibernateの得意な部分は活かしつつ、 参照系ではまりがちなHibernateの使い方に悩む時間を一切カット (クエリを書いた通りに動く) ◦ 検索条件の拡張も快適
75. • 実際どうだった？ →かなり使い勝手が良いです！！ • Read Model ◦ Hibernateの得意な部分は活かしつつ、 参照系ではまりがちなHibernateの使い方に悩む時間を一切カット (クエリを書いた通りに動く) ◦ 検索条件の拡張も快適 • Write Model ◦ DDDとSpring Data JPAの相性は抜群 　RepositoryのIFだけ書けば実装クラスを作ってくれるのはとても楽 ◦ writeモデルに振る舞いを凝縮している安心感、読みやすさ◎ 導入結果
76. Q&A
77. Q&A • そもそも2つのORM同時に使っていいの？
78. Q&A • そもそも2つのORM同時に使っていいの？ →前述の通りjOOQ公式で紹介されている使い方 (@little_hand_s から参考資料たどれます 「jOOQ関連リンク」)
79. Q&A • テストはどうしている？
80. Q&A • テストはアプリケーション層のメソッドに対して書く (ちなみにspock) • メリット： ◦ 費用対効果が良い ◦ 内部のリファクタがしやすい ◦ アプリケーションサービス層で担保すれば、 呼び出し元がAPIだろうが画面だろうが watcherだろう が安心感がある • デメリット： ◦ テストでのDB実行環境構築が必要 Application Service Domain Model Query Model User Interface Infrastructure • テストはどうしている？
81. Q&A • 要件として参照と更新を同時に行う必要がある場合は？ 例：ある情報を参照したら参照ログを残したい
82. Q&A • 要件として参照と更新を同時に行う必要がある場合は？ 例：ある情報を参照したら参照ログを残したい • 対策1： ApplicationServiceを複数呼び出す処理を書く ファサードのようなレイヤなど。 通常のApplicationServiceとは区別するのがよい • 対策2： ドメインイベントを発行してWatcherで拾い、非同期的に更新を行う
83. Q&A • アプリケーションサービスはコマンド系・クエリ系でクラスを分ける？ Application Service Domain Model Query Model User Interface Infrastructure
84. Q&A • アプリケーションサービスはコマンド系・クエリ系でクラスを分ける？ → 分けたほうが使用するモジュールにに間違いないことが判別しやすい。 でもどちらも可 Application Service Domain Model Query Model User Interface Infrastructure
85. • QueryServiceはUIから直接参照させてもよいのでは？ Q&A Application Service Domain Model Query Model User Interface Infrastructure <<interface>> Query Serivce DTO Query Serivce Impl
86. • QueryServiceはUIから直接参照させてもよいのでは？ →どちらでも可、要件次第。 　今回はApplicationServiceを挟んでよかった。 ◦ テスト単位がApplicationServiceというレイヤで統一できる ◦ 単純な条件抽出以外の処理を分岐したい場合、 その制御をApplicationServiceに任せられる ▪ 操作ユーザーの情報に応じて 処理を分岐 ▪ 権限制御、抽出条件変更など Q&A Application Service Domain Model Query Model User Interface Infrastructure <<interface>> Query Serivce DTO Query Serivce Impl
87. まとめ
88. まとめ • CQRSは要件に応じて柔軟にやり方を変えられる • Write/Readモデルを分けるときにORMを分けるのは、 モデルを分けるメリットを大きくできる • ぜひご検討してみてください • ご意見、ご質問は @little_hand_s もしくは#ccc_m4 まで
89. ありがとうございました