JJUG CCC 2024 Fall：Spring ModulithによるDDDとEvent-driven Architectureの実践

11.9K Views

October 25, 24

#jjug_ccc #java #spring #spring-boot #spring-modulith #modular-monolith #アーキテクチャ #ddd #イベントドリブン #DDD #ドメイン駆動設計 #Spring Modulith #モジュラモノリス #マイクロサービス

スライド概要

JJUG CCC 2024 Fallでのスポンサーセッション「Spring ModulithによるDDDとEvent-driven Architectureの実践」の公開資料です。

シンプレクス株式会社

@Simplex

スライド一覧

シンプレクスは1997年の創業以来、メガバンクや大手総合証券を筆頭に、日本を代表する金融機関のテクノロジーパートナーとしてビジネスを展開してきました。現在では、金融領域で培った豊富なノウハウを活用し、金融機関以外の領域でもソリューションを展開しています。2019年3月にはAI企業のDeep Percept株式会社、2021年4月には総合コンサルティングファームのXspear Consulting株式会社がグループに加わり、創業時より付加価値の創造に取り組んできたシンプレクスとワンチームとなって、公的機関や金融機関、各業界をリードする企業のデジタルトランスフォーメーション（DX）の推進を支援しています。

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

（ダウンロード不可）

関連スライド

JJUG CCC 2024 Spring：テストコードが根付くチームを立ち上げるために考えたいこと

java jjug_ccc

シンプレクス株式会社 83.4K

JJUG CCC 2023 Fall : クライアントワークでドメイン駆動設計を活用してみてた

ドメイン駆動設計 ddd java

シンプレクス株式会社 17.6K

Gradleと仲良くなる第一歩　～小規模PJから大規模PJへ～

java jjug_ccc gradle

シンプレクス株式会社 15.1K

JJUG CCC 2022 Spring_保険基幹システムのアーキテクチャ_シンプレクスの技術的チャレンジ

基幹システム保険 camunda スキーマレス・アーキテクチャ

シンプレクス株式会社 10.9K

Gaugeで学ぶ実行可能ドキュメントの価値

java jjug_ccc

シンプレクス株式会社 10.9K

振り返ったら最高のPBL研修だった　研修と実務のギャップをきっかけに更に学んだ実体験

pbl エンジニア研修

シンプレクス株式会社 9.2K

各ページのテキスト

What is Simplex Inc. 金融事業領域を中心にビジネスパートナーとしてお客様の収益力強化、生産性向上を支援しています。近年は官公庁、製造業といった非金融領域に対してもシステム・ソリューションを提供しています。シンプレクス・ホールディングス社名シンプレクス株式会社事業内容 • コンサルティングサービス • システム開発 • 運用保守 • ASPサービス提供等代表取締役社長金子英樹創業年月日 1997年9月16日資本金 4,750 百万円（2024年3月31日現在）連結従業員数 1,554名（2024年4月1日現在）株主シンプレクス・ホールディングス株式会社テックファーム本社所在地東京都港区虎ノ門1-23-1 虎ノ門ヒルズ森タワー19階 1997年創業（東証プライム：4373）シンプレクスクロスピアビジネスプラットフォームの構築 “IDC FinTech Rankings”に13年連続で選出 DXビジネス戦略の立案コンサルファーム 2021年創設 AWSパートナーネットワークにおける認定 2 © 2024 Simplex Inc.

What is Simplex Inc. シンプレクスは、金融から開始し、様々なweb3サービス構築を行っています 2018 業界別対応実績暗号資産交換所 2019 2022 デジタル証券（STO） 2024〜新領域への活用ゲーム・エンタメステーブルコイン対応技術領域コントラクト・ウォレット NFT FT（暗号資産・ST・ステーブルコイン）プライベートチェーンパブリックチェーン 3 © 2024 Simplex Inc.

What is Simplex Inc. サービス提供形態クライアントのニーズにあわせた形で体制を組成、サービス提供を行っています。プロダクト提供プロフェッショナルサービスグループの強みを活かし、各種プロフェッショナルが、クライアントと一体となってサービス企画から構築、運用保守、継続拡張を一貫して支援 Xspear Consulting ・大手コンサルの経験者・各種業界の経験者 Simplex Inc. ・web3技術エキスパート・大規模PJを完遂する実行力・金融水準の運用保守個社カスタマイズ型 SaaS型ベースパッケージを活用、個社カスタマイズで、独自性に注力 SaaSを活用しクイックにPoCやサービス立ち上げを実施 Simplex Crypto Assets Simplex Fourth 暗号資産交換所システムウォレットを軸としたweb3プラットフォーム Simplex Digital Securities Simplex Dealing Cloud デジタル証券取引システム暗号資産ディーリング Simplex NFT Deep Percept マケプレ・GameFi・推し活等など・データ分析・AIモデル構築 Simplex Stablecoin Stablecoinの発行・償還 Alceo ・UI/UXデザインに特化 4 © 2024 Simplex Inc.

モノリス~モジュラモノリス~マイクロサービスモノリスモジュラモノリス単一サービス単一サービスユーザ機能入金機能ユーザ機能入金機能通知機能通知機能マイクロサービスユーザサービス入金サービス通知サービスユーザ機能入金機能通知機能共通ロジック単一のサービス内に様々な機能を実装する単一のサービスの中でモジュールを分割してモジュール間の依存を明確にする 8 複数のサービスに機能・データストアを分割して、複数のサービスを独立させる © 2024 Simplex Inc.

10.

アーキテクチャごとの特徴プログラミングインフラモノリスモジュラモノリスマイクロサービス再利用・共有化しやすいモジュール間の依存に制約を付けられるロジックの共通化は比較的容易サービス間の依存がAPIに限定されるロジックの共通化に対する制約が強いトランザクション管理が難しい構成がシンプル機能ごとのデプロイやスケーリングはできない特定の箇所の障害がサービス全体に波及する技術選定の自由度が高い独立したデプロイ/スケーリングが可能特定の箇所の問題が全体に影響しずらいサービス間のやり取りでネットワーク通信が発生する 9 © 2024 Simplex Inc.

11.

12.

13.

なぜモジュールの分割を行いたいのか “モジュールは長い歴史を持つ確立された設計要素である。技術的な考慮も一因ではあるが、認知のための負荷を下げることがモジュール化にあたって主要な動機になっている。(中略) 全体によって圧倒されることなくモジュール内部の詳細を見ることができるし、その一方で内部の詳細を無視したうえでモジュール間の関係性を見ることもできるのだ。(中略) モジュール間では低結合、モジュール内では高凝集が必要なのは自明の理だ。” Eric Evans.『エリックエヴァンスのドメイン駆動設計』.翔泳社.2011年,108p 12 © 2024 Simplex Inc.

14.

なぜモジュールの分割を行いたいのかマイクロサービスユーザサービス入金サービス通知サービス API API API ユーザ機能入金機能通知機能モジュラモノリス API API API ユーザ機能入金機能通知機能モジュールをまたいだロジックの呼び出しは APIを経由しなければならない • 依存箇所がAPIに限定される →低結合 • 機能に関連したロジックが外部に散らばりづらい →高凝集共通ロジック 13 © 2024 Simplex Inc.

15.

16.

17.

システムを独立管理したい事情があるかを考える • 開発メンバーの人数が大規模 • 大規模チームはそれだけで難易度が上がる 10人-20人以上なら分割を検討してそれぞれを独立した別サービスとして扱う (cf.2ピザチーム,コンウェイの法則) • コード行数が多すぎて、CI/CDに時間がかかりすぎる • コンパイル・テスト・ビルド・デプロイ・静的解析などに時間がかかりすぎると、それだけでいろんなところに悪影響 • 開発端末のスペックやテストの書き方にも依存するので一概には言えないが、感覚的にはコード行数50-100万行あたりから徐々にこの問題が大きくなる印象 • スペックアップで対処できるならそれが早い。サービスの寿命とコストのかけどころのバランスで判断が必要 16 © 2024 Simplex Inc.

18.

システムを独立管理したい事情があるかを考える • 開発言語など利用する技術を機能に応じて変えたい例： • いつもはKotlinでサーバ開発しているけど、機械学習関係のロジックは Pythonで書きたい • 機能ごとに非機能要求のレベルが大きく異なる例： • アカウント管理・送金処理周りのセキュリティ要件が厳しい • イベントに関連したキャンペーンサイトを新たに作るのでここだけ突発的な負荷かかりそう 17 © 2024 Simplex Inc.

19.

結局こうなりました • 高凝集/疎結合のためにモジュールの境界は厳密に設計する • 事情があれば別サービスに分ける • 開発体制の分割や、特別な技術要素・非機能要件がある場合 • 「トランザクションが分断される」「ネットワーク通信が発生する」という制約は考慮する • 他はモジュラモノリスの汎用サービスで開発開発チーム開発チーム UI UI ビジネスモジュール高セキュリティ要件なサービスなど汎用サービス特化サービス UI ビジネスモジュールビジネスモジュールビジネスモジュールビジネスモジュール一時的なサービスビジネスモジュール共通ロジック 18 © 2024 Simplex Inc.

20.

21.

Spring Modulithとは？ “Spring Modulith は、Spring Boot を使用してドメイン駆動型のモジュール型アプリケーションを構築するための独自のツールキットです。その結果、Spring Modulith を使用すると、開発者は更新が容易なアプリケーションを構築して、時間の経過とともに変化するビジネス要件に対応できるようになります。” DDDを意識したライブラリ Spring Modulith(2024-10-20時点) https://spring.pleiades.io/spring-modulith/reference/ 20 © 2024 Simplex Inc.

https://spring.pleiades.io/spring-modulith/reference/

22.

23.

24.

モジュールの分割モジュール・公開部分・依存関係の定義をすると、Spring Modulith が構造をテストしてくれる。 Example/ └src/main/java/example ├─MainClass.java ├─user/ │ ├──UserApi.java │ ├──usecase/ │ ├──domain / │ └──infra / ├─payment/ │ └──・・・(同上) ├─notice/ │ └──・・・(同上) └─common/ デフォルトでは MainClassの直下がモジュールになるモジュール直下デフォルトではモジュールの最上段が公開 APIになる共有したいロジック置き場も作れる (Log・Spring Security・Feature Flag) 23 user payment notice 公開公開公開内部ロジック内部ロジック内部ロジック domain usecase infra common 公開 © 2024 Simplex Inc.

25.

モジュールの分割テストでもモジュール性を重視する • ドメインテストアーキテクチャテスト • ドメインロジックを対象としたテスト • レポジトリテスト user payment notice モジュール直下 API テスト API テスト API テスト • APIテスト domain ドメインテストドメインテストドメインテスト • • 検索クエリなどのロジックのテスト • モジュール単体を対象にしたAPIを実行するテスト • アーキテクチャテスト • モジュールのルール違反を検出するテスト usecase infra 他モジュールのAPI呼び出しはMock化するレポジトリテストレポジトリテスト • • • レポジトリテスト公開していないコードにアクセスしてないかモジュールの依存関係の定義から逸脱してないか依存関係の循環が発生していないか • レイヤー間の依存関係もテスト • common 24 ここではArchUnitを使ってる © 2024 Simplex Inc.

26.

モジュール分割やって見た感想いい点気を付けるべき点 • 開発時に迷いがなくなる • モジュールの境界線を決める難しさ • ドメインの設計時点でモジュールのことまで意識するので開発者ごとの考え方のブレが少なくなる • (その分設計が白熱する) • 境界づけられたコンテキストを探す工程が必要 • 設計難易度は上がる • モジュールの循環依存に悩まされて、リファクタしたりしました • 1つのユースケースだと思っていたのに、2つの APIに分けて整理したり • 影響範囲の把握が楽 • コアな箇所の修正でもAPIに影響を出さなければ他モジュールへの影響は気にしない(強い意志) • テストコードの存在があって初めて威力を発揮する • 何かあったときのリスクが少ない • リファクタレベルの修正でモジュール化できる • 最悪モジュール統合しちゃえばモノリスと同じ扱いに戻せる安心感 • もしSpring Modulithがバグっていてもサービスに影響がない安心感 • そもそもモジュール検証機能もテストなので、開発の中で常に自動テスト結果を確認する文化が必要 • モジュール外への影響が出てないかは最終的にはテストで担保されるもの 25 © 2024 Simplex Inc.

27.

https://www.docswell.com/s/Simplex/ZRXNDN-simplex_maeda01/1

28.

29.

30.

Request・Responseの時 @Service payment class PaymentService( val service:NoticeService, ) { @Transactional fun postPayment(payment: Payment) { payment.complete(); service.sendMail(payment.user.mail); } } @Component class NoticeService{ fun sendMail(mail:string) {/** */} } notice 29 © 2024 Simplex Inc.

31.

32.

同期イベント連携のとき @Service payment class PaymentService( val events: ApplicationEventPublisher, ) { @Transactional fun postPayment(payment: Payment) { events.publishEvent(payment.complete()); } } @Component class NoticeService{ fun sendMail(mail:string) {/** */} notice @EventListner fun on(event: PaymentCompleted) { sendEmail(event.user.mail); } } 31 © 2024 Simplex Inc.

33.

同期イベント連携のとき @Service payment class PaymentService( val events: ApplicationEventPublisher, ) { @Transactional fun postPayment(payment: Payment) { events.publishEvent(payment.complete()); } } @Component class NoticeService{ fun sendMail(mail:string) {/** */} @EventListner fun on(event: PaymentCompleted) { sendEmail(event.user.mail); } notice API 入金機能 API 通知機能 noticeが paymentに依存する } 32 © 2024 Simplex Inc.

34.

非同期イベント連携のとき @Service payment class PaymentService( val events: ApplicationEventPublisher, ) { @Transactional fun postPayment(payment: Payment) { events.publishEvent(payment.complete()); } } @Component class NoticeService{ fun sendMail(mail:string) {/** */} notice @ApplicationModuleListener fun on(event: PaymentCompleted) { sendEmail(event.user.mail); } } 33 © 2024 Simplex Inc.

35.

非同期イベント連携のとき @Service payment class PaymentService( val events: ApplicationEventPublisher, ) { @Transactional API funAPI postPayment(payment: Payment) { 入金機能通知機能 events.publishEvent(payment.complete()); } } noticeが paymentに依存する paymentが @Component notice noticeの遅延や失敗の class NoticeService{ fun sendMail(mail:string) {/** */} 影響を受けない @ApplicationModuleListener fun on(event: PaymentCompleted) { sendEmail(event.user.mail); } } 34 © 2024 Simplex Inc.

36.

37.

Spring Modulithでイベント連携やって見た感想いい点気を付けるべき点 • 記述が簡単 • 非同期イベントは順序を制御できない • FIFOで順番に処理するなどの構造はとれない • 結合テストとの統合が用意されている • 非同期イベントがテーブルに依存する • イベント発生のたびにテーブルにレコードが発生し続けるので、自身でライフサイクルの管理が必要 • 今は管理用のインターフェースが存在しているので管理しやすくなってる(v1.2系) • イベントの外部化とも組み合わせると、いい感じに他マイクロサービスとも連携が取れそう • 非同期イベントはかなり改善されてきているので今後に期待 • スケールアウト構成の場合の挙動が怪しかった(V1.0系当時) 36 © 2024 Simplex Inc.

38.

39.

アーキテクチャを検討する前に考えてほしいこと • モジュラモノリス・マイクロサービスは組み合わせてもいい • モジュールの分割に関するアプローチとしてモジュラモノリスは良い選択肢 • マイクロサービスが不要になるわけではない • ビジネスの特性を考慮しましょう • モジュールの境界線を設定するには分析が必要 • 結局これが重要で難しい。。。 DDDのアプローチが助けになる • 議論しながら業務の都合とシステムの都合をすり合わせて進めましょう • 未知の領域に挑むならモノリスで始めて、ドメイン知識の獲得を待つのもあり • モジュラモノリスならマイクロサービスよりは失敗したときの痛手が少ない 38 © 2024 Simplex Inc.

40.

Spring Modulith開発において気を付けるポイント • モジュールの境界線を決めたら頑張って守る • 追加開発をしていくと、制約が邪魔に感じることはあるけどあきらめないその制約があることでシンプルさが生まれると思う。まずは頑張って考える • Reqeset/Response・同期イベント・非同期イベント使いこなそう！ • 単一ドメイン、単一モジュール、モジュール間テストそれぞれの観点でテストピラミッドを意識したテストを実施する 39 © 2024 Simplex Inc.

41.

Spring Modulith開発において気を付けるポイント • Spring Modulithの非同期イベントを使う場合は、非機能観点のテストをしっかりやりましょう • イベント連携周りはシステムの根幹部分になるので、モジュールの分割のように気軽な判断は難しい • 今回は非同期イベントについてはFIFOキューで管理したい箇所があるので、 SQS+SpringAWSの慣れてる方式をつかいました • 去年時点(v1.0系)ではリトライやマルチプロセスでの挙動に不安を感じた。 • 今は(v1.2系)イベント管理が進化している部分もあるので使う選択肢があるかもしれません！ 40 © 2024 Simplex Inc.

42.