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

JJUG CCC Fall 2023 クライアントワークで ドメイン駆動設計を活⽤してみた 2023/11/11(⼟) 浦⻄雄哉 シンプレクス株式会社 1 © 2023 Simplex Inc.

Speaker 浦⻄ 雄哉（うらにし ゆうや） シンプレクス株式会社 クロスフロンティアディビジョン アソシエイトプリンシパル 資格: AWS Solution Architect Professional 経歴 ⼊社以来クラウドを利⽤した⾦融領域のプロジェクトにて開発を中⼼に要件定義から移⾏までの全⼯程を担当 現在は開発リードとしてアーキテクチャ検討やチームマネジメントしつつ、開発者としてコーディングも⾏う 趣味 バイク、旅⾏ 2 © 2023 Simplex Inc.

シンプレクスについて 1997年創業のITコンサルティング企業 IT戦略から開発、運⽤まで⼀気通貫で担い、 トータルソリューションを提供 しています 創業当時より ⾦融フロント・ミドル領域 に強みを持ち、 市場業務、リテール⾦融業務に多数の実績 2013年より 保険領域 にビジネスを拡⼤し、現在に⾄るまで実績 多数 各種領域で ⾃社パッケージ・フレームワーク・ライブラリの開発・ 活⽤ により業界知識集約・⽣産性向上を図っています 近年は⾮⾦融領域へもビジネスを展開しています 3 © 2023 Simplex Inc.

ドメイン駆動設計（Domain-Driven Design、DDD）とは DDDとは • 顧客/有識者(ドメインエキスパート)と開発者が共通⾔語(ユビキタス⾔語)を通して、ドメイ ンモデルを構築し、モデルをソフトウェアで表現すること 利点 • 業務をソフトウェアで表現することで業務の変更に対して変更容易性を⾼めることができる • 業務理解を深めることで、ソフトウェアの要件やビジネスルールを明確にすることができる • チーム内でのコミュニケーションや共有理解を促進する効果がある 4 © 2023 Simplex Inc.

DDDの思想を取り⼊れて期待できる効果 ドメイン知識を 開発者とドメイン 知識を持つ⼈と 反復的に 発展できる の共通⾔語がで きる 変更が容易なアプリケーションに︕ 業務と実装が 結びつく 5 © 2023 Simplex Inc.

今回はなすこと 1. プロジェクトについて 2. DDDを採⽤した経緯 3. 実際にやったこと 4. 実際にやった結果 5. まとめ&QA 6 © 2023 Simplex Inc.

プロジェクトについて 今回お話するPJ • 弊社にとっての新しい領域の顧客 • ウォーターフォールでのフルスクラッチ開発 構成 • AWS Fargateでアプリケーションを稼働 • バックエンド: Java17 + Spring Boot(2.7) • フロントエンド: TypeScript + Vue3 規模 • バックエンドのKLOC: 140 • ⼈数: 開発者30⼈ • 期間: 1.5年 (開発期間: 6か⽉) 7 © 2023 Simplex Inc.

今回話すこと 1. プロジェクトについて 2. DDDを採⽤した経緯 3. 実際にやったこと 4. 実際にやった結果 5. まとめ&QA 8 © 2023 Simplex Inc.

DDD採⽤の経緯 運⽤・保守の⽴ち上がり労⼒を割くPJにいくつか携わっていた ü業務とソースの乖離が存在し、変更点が不明瞭 DDD有識者のサポートを依頼 ü新規参⼊者のキャッチアップが難しい ü DDD第⼀⼈者の増⽥ 亨⽒に参画して頂き、 講義・ワークショップやPoCにご協⼒いただいた。 ü体制縮⼩に伴うメンバーの⼊れ替え 著書 『現場で役⽴つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法』 感じていた課題 DDDの活⽤事例調査 DDD採⽤準備 PJ開始 DDD活⽤事例の収集 ü書籍（エヴァンス本、IDDD本） üブログ・サイト üJJUG CCCの過去資料 9 © 2023 Simplex Inc.

1. プロジェクトについて 2. DDDを採⽤した経緯 3. 実際にやったこと 4. 実際にやった結果 5. まとめ&QA 10 © 2023 Simplex Inc.

実際にやったこと概要 要件 定義 外部 設計 内部 設計 開発 テスト ▸ モデルを作成する ▸ チーム編成をきめる ▸ システムのアーキテクチャを考える ▸ コンテキスト間のデータ連携⽅法を決める ▸ ソースコードの構成を決める 11 © 2023 Simplex Inc.

モデルを作成する RFPや業務フローなどから概念モデル図(≒ドメインモデル)を作成 • 最も重要なモデルは何かなど重要度の濃淡も付ける • ドキュメントやソースコードの⽤語に⽤いることをPJのルール化をして、開発期間を通して共通⾔語(ユビキタス⾔語)としてメン テンナンスしていく • また同じ⾔葉でも⽂脈異なるによって意味が変わるものがないか注⽬する 責務を複数持っているドメインがいないかを確認 • 依存が多い場合や、そもそも主語が異なるものは分割できることが多い 業務領域(境界づけられたコンテキスト)を定める • 上記を⾏っていくうちに同じ⾔葉でも異なる意味で表現されているものが⾒つかるのでそれぞれの業務の境界を分ける 12 © 2023 Simplex Inc.

チーム編成を決める コンテキストごとにチームを編成する • コンテキストが多い場合は1チーム複数コンテキストを担当する。ドメインモデルはこのチームごとに更新を⾏っていく イテレーション開発をする計画を作る • ドメインモデルを継続的に発展させていくことになるのでウォーターフォール型でも設計開発はイテレーションで実施したほうがよ い。また重要なドメインの開発が後回しにならないようにスケジュールを⽴てていく。 チームが⼤きくなりすぎる場合はコンテキストを分けられないかチェックする • あまりにも⼤きいチームで進めているとユビキタス⾔語の⽅⾔が⽣まれてしまう。その⽅⾔が出てきて初めてコンテキストを分けら れることに気づくことも多い • チームが⼤きいからといって無理に分けてしまうと、キャッチアップコストやモデルの統⼀するコストが発⽣するので、どこかで妥協 をすることになる A業務 B業務 Aチーム7人 Bチーム15人 Cチーム8人 １チームにし ては⼤きい C業務 13 © 2023 Simplex Inc.

システムのアーキテクチャを考えるーコンテキストごとにプロセスを分ける コンテキストごとにプロセスを分ける • • ⼀般的にコンテキストによって区切られた業務は特性が異なるためプロセスを分けておくと、リソースの調整がしやすい システム間も疎結合になるのでマイクロサービス化もしやすくなる 処理も少なく、緊 急性も少ないので ⼩さくてもよい フロント エンド 認証 認可 プロセス A業務 プロセス コア業務でリソースが 豊富に必要 B業務 プロセス 外部IF 外部IF プロセス プロセス C業務 プロセス 可⽤性を担保する必 要があるので複数台 構成 外部 システム © 2023 Simplex Inc.

コンテキスト間のデータ連携⽅法を決める モデルをコンテキストをまたいで共有(共有カーネルパターン) • プロセス間のインターフェースでオブジェクトをSerialize/Deserializeするため、コンテキスト間でモデルを共有 モデルを変換する層を設ける(腐敗防⽌パターン) • フロントエンドや外部システムで⽤いているモデルを分離するため、モデル変換する層を実装する A業務 プロセス フロント エンド 認証 認可 プロセス B業務 プロセス 外部IF 外部IF プロセス プロセス 外部 システム C業務 プロセス 15 © 2023 Simplex Inc.

ソースコードの構成を決める • 異なるチーム間でモデルを共有しており継続的な統合が必要になるため、まとめて⾃動テストがしやすいモジュラ モノリスで構成 • モジュール内のパッケージ構成はLayered Architectureベースで構成 • アプリケーション層からインフラストラクチャー層はインタフェースとDIを使い依存性を逆転 モジュール構成 A 業務 パッケージ構成 B 業務 C 業務 UI層/プレゼンテーション層 (@Controller) アプリケーション層 (@Service) ドメイン層 インフラストラクチャー層 (@Repository) 共有モデル 16 © 2023 Simplex Inc.

実際にやったことの概要 要件 定義 外部 設計 内部 設計 開発 テスト ▸ 設計書の作成のサイクルを決める ▸ 実装する ▸ PJ参画メンバーの育成 17 © 2023 Simplex Inc.

設計書を作成するフローを決める 画⾯設計 業務フロー ビジネスルール ファイル・帳票定義 設計を固める順番は、 「業務フロー」や、ユビキタス⾔語をもとにした 「ビジネスルール」が先。 画⾯設計やファイル・帳票定義などは その後。 要件定義時の資料からモデルを起こした後も、 開発者の理解の深まりに合わせてドメインモデ ルを継続的に⾒直す ドメインモデル ユビキタス⾔語 18 © 2023 Simplex Inc.

実装（ドメイン層の実装: モデルをクラス化） バリューオブジェクト 従業員:Employee -----------------------------(PK)従業員ID : EmployeeId ⽒名:FullName 部⾨: Department ステータス: EmployeeStatus 区分値 DDDにおけるエンティティ 19 © 2023 Simplex Inc.

実装（ドメイン層の実装: 設計書をもとにモデルにロジックを⾜していく） バリデーションを ドメインに寄せる ステータス遷移 20 © 2023 Simplex Inc.

実装（アプリケーション層の実装: モデルを呼び出す。インターフェースを作成する） • 書いていきながら、ドメインクラスに隠ぺいすべき情報があればリファクタリングをしていく（単純な例は下記） • RepositoryはInterfaceだけを切っておいて先に進める。 • サービス（@Service）には状態やロジック（分岐やループ）は極⼒持たない 21 © 2023 Simplex Inc.

実装（アプリケーション層の実装: モデルを呼び出す。インターフェースを作成する） • 書いていきながら、ドメインクラスに隠ぺいすべき情報があればリファクタリングをしていく（単純な例は下記） • RepositoryはInterfaceだけを切っておいて先に進める • サービス（@Service）には状態やロジック（分岐やループ）は極⼒持たない 22 © 2023 Simplex Inc.

Embeddable @Embedded 実装（インフラストラクチャー層の実装） • RepositoryのInterfaceの継承先を実装する。ネストしたクラスを永続化するO/Rマッパーの選択は悩むポイント • 今回は両⽅試してみてMyBatisを採⽤した Spring Data JPA MyBatis • Spring Projectのライブラリ。使ったことがある⼈が多い。 • テーブルに対応したクラスが必要になる。 • 階層の深いドメインを永続化しようとすると @AttributeOverrideなどのアノテーションをつける必要 がありインフラストラクチャー層の知識が露出する。避ける 場合はコード量が増える • XMLでテーブル<->クラスの依存を吸収可能。 • クラスの階層が深くなると凡ミスを起こす可能性。テストは MybatisTestで簡単に書くことができる 23 © 2023 Simplex Inc.

PJ参画メンバーの育成 業務理解(what)と実装スキル(how)の両⽅に解像度の⾼い開発者・チームになることが求められる • 開発メンバーが効率的なスキルアップができるようにフォローする取り組みを実施 ⾼ ⽬標のスキル スキルのあげ⽅ ドメインエキスパートとの会話。勉 強会。設計を読む・書く 業 務 理 解 度 勉強。ソースコードを読む・書く モブプロ・ペアプロ 当初のスキル 低 ⾼ 実装スキル © 2023 Simplex Inc.

1. プロジェクトについて 2. DDDを採⽤した経緯 3. 実際にやったこと 4. 実際にやった結果 5. まとめ&QA 25 © 2023 Simplex Inc.

今回DDDの取り組みで改善したこと:保守性の向上 • 理解容易性: • ソースコードの複雑さを表す指標である「認知的複雑度」が 「10以下」のメソッドが全体の 98.8%を占めた • 設計と実装の対応の明確であるため、仕様変更の影響箇所の特定、修正がはるかに容 易になった • 変更容易性: • 影響範囲の明確なコードになりやすかったため、修正も容易になった • 結果として、仕様変更が⼊っても着⼿からリリースまでの期間が短くなった 26 © 2023 Simplex Inc.

今回のDDDの取り組みで苦労したこと: コンテキスト境界の遵守 • コンテキスト境界に基づいたチーム分割の遵守 • プロジェクトの後半にスケジュール都合等により、コンテキスト境界を跨いだ実装タスクの担 当が発⽣せざるを得なかった • コンテキスト境界内に対して理解度の⾼いチームであるがゆえに、想定しないキャッチアップ コストが必要となった • 本来そのコンテキストのオーナーシップを持つチームが実装タスクのフォローやコードレビュー だけでも⾏うように対策を取った • コンテキストを跨いだ意図せぬ依存が混⼊ • 共有カーネルパターンを適⽤し、コンテキスト間でモデルを共有したことのデメリットのひとつ • ツールやテストを⽤いて継続的に依存関係を検査する必要があったので、今後は改善し ていきたい 27 © 2023 Simplex Inc.

1. プロジェクトについて 2. DDDを採⽤した経緯 3. 実際にやったこと 4. 実際にやった結果 5. まとめ&QA 28 © 2023 Simplex Inc.

まとめ-DDDの思想を取り⼊れて期待できる効果 ドメイン知識を 開発者とドメイン 知識を持つ⼈と 反復的に 発展できる の共通⾔語がで きる 変更が容易なアプリケーションに︕ 業務と実装が 結びつく 29 © 2023 Simplex Inc.

まとめ-最後に ドメイン駆動設計を実現するためのパターンは数多くありそのまま取り⼊れるのではなく、 ドメイン駆動設計の思想を守りつつPJの特性に合わせて参考になるパターンを取捨選択して ⾃分たちなりの⼿法を確⽴しよう! © 2023 Simplex Inc.

ご清聴ありがとうございました 32 © 2023 Simplex Inc.