事業価値を生み出すモデリング 価値をサステナブルにするアーキテクチャ

このスライドでは、ドメイン駆動設計の手法を用いて、
モデリングで機能性を高め、
アーキテクチャと実装パターンで保守性を高める方法を紹介します。

ドメイン駆動設計のモデリング手法として、シンプルな4つの図でモデリングできる"sudoモデリング"の事例を紹介し、それをコードに落とし込むためにどのようなアーキテクチャが必要かを解説します。

# 関連資料

ドメイン駆動設計 サンプルコード&FAQ
https://little-hands.booth.pm/items/3363104
今回の内容はこちらからの抜粋です。DDDに関して頻出の質問に、多くのサンプルコードを交えて回答した解説書です。
モデリング、集約の実装、テストについても具体例を交えて解説しています。

## 実装方法に関しての解説動画
10分でわかるドメインモデルをコードに落とす方法
https://www.youtube.com/watch?v=Upeg6cNOirc
DDDの「集約」コードを見れば一発でわかります。
https://www.youtube.com/watch?v=Hn4EAXYBl8c

# SNS・質問箱
Xはこちら
https://x.com/little_hand_s

匿名で質問できる質問箱はこちら
https://querie.me/user/little_hand_s

DDD勉強会/設計相談サポート内容のご紹介
https://www.notion.so/DDD-22429f7110574439a4c3e126c20fa9a2?pvs=21

ログラスProductTeam公式X
https://twitter.com/LoglassPrdTeam

ログラスの求人内容
https://hrmos.co/pages/loglass/jobs/1813462408235663415

Transcript

1. 松岡 幸一郎 (@little_hand_s) 2024/5/22 事業価値を生み出すモデリング 価値をサステナブルにするアーキテクチャ 1
2. • 名前 ◦ 松岡 幸一郎 (@little_hand_s) • 所属 ◦ 株式会社ログラス 経営管理領域でDDDを実践中 • 発信 ◦ 「ドメイン駆動設計 サンプルコード＆FAQ」 「ドメイン駆動設計 モデリング/実装ガイド」執筆 ◦ 質問箱 (DDD関連の匿名質問受付) ◦ DDD関連の技術ブログ ◦ Youtube DDD解説動画チャンネル • その他活動 ◦ 企業様へのDDD導入/設計サポートなど 自己紹介 2
3. • 日本アイ・ビー・エム ◦ 金融機関のお客様でミッションクリティカルなシステム開発 • ビズリーチ ◦ レガシーコードとの戦いの中で、アジャイル開発の手法と出会う ▪ スクラム、エクストリームプログラミング、テスト駆動開発 ◦ 新規プロジェクトでドメイン駆動設計の開発 • ログラス ◦ アジャイル、DDDを開発組織全体に浸透 経歴 3
4. 4 ©2024 Loglass Inc. 企業価値を向上する 経営管理クラウド
5. 5 ログラスProductTeam公式Xはじまりました！ https://twitter.com/LoglassPrdTeam
6. • ドメイン駆動設計の手法を用いて、 モデリングで機能性を高め、 アーキテクチャと実装パターンで保守性を高める方法を紹介します。 • 機能性→事業価値を高める • 保守性→開発をサステイナブルにする 本日のお話 6
7. アジェンダ • モデリングの必要性とDDDのアプローチ • モデリング方法 • モデルと実装のつながり • DDDのアーキテクチャ • DDDの実装パターンの参考情報 7
8. • ソフトウェアはなんのために作るのか？ 8
9. • ソフトウェアを適用する対象の何らかの問題を解決するため 9
10. • ドメイン駆動設計の文脈では、 この「ソフトウェアで問題解決しようとする対象」を「ドメイン」と呼ぶ 10
11. DDDの言葉の定義を確認 DDD Reference: DomainLanguage.comにあるDDDのエッセンスの要約版 Evans本よりだいぶまとまっているので、定義などに迷ったらまずこちらを参考に 11
12. DDDとは • DDD： DomainDrivenDesign(ドメイン駆動設計)の略 • DDD Referenceより "多くのプロジェクトは、モデリングを行っても 最終的に大きな利益を得られないまま終わります。 DDDは、モデリングから劇的な利益を得られたプロジェクトから、 成功するパターンを抽出します。” 12
13. DDDとは • DDD： DomainDrivenDesign(ドメイン駆動設計)の略 • DDD Referenceより "多くのプロジェクトは、モデリングを行っても 最終的に大きな利益を得られないまま終わります。 DDDは、モデリングから劇的な利益を得られたプロジェクトから、 成功するパターンを抽出します。” 13
14. • ①ソフトウェアの機能性を高めること → 役に立つものを作る 　「作ったけど使えない」を避ける • ②ソフトウェアの保守性を高めること → 長期間開発しても機能拡張が容易でありつづける 　 「技術的負債でどんどん開発速度が低下する」を避ける DDDでは 役に立つソフトウェアを、長期間保守性を下げずに作り続けられるようにする ことを目指します DDDの目的 14
15. • ①機能性向上へのアプローチ → ドメインエキスパートと共に行うドメインモデリング ◦ 「ドメインモデル」という抽象化物にドメインの知識を反映することで、 役に立つものになる可能性を高める ◦ 開発初期だけではなく、各フェーズで得られた発見をこまめに フィードバックすることで改善頻度を上げる • ②保守性向上のためのアプローチ → 頻繁なモデルの更新に耐えられる実装パターンとアーキテクチャ ◦ モデルの形をそのままコードで表現し、モデルの変更を反映しやすくする ◦ 頻繁な更新に耐えられるように、 保守性の高いデザインパターン(エンティティ、リポジトリ等)を適用する ◦ そのパターンを実現しやすいアーキテクチャを活用する DDDのアプローチ(1/2) 15
16. アジェンダ • モデリングの必要性とDDDのアプローチ • モデリング方法 • モデルと実装のつながり • DDDのアーキテクチャ • DDDの実装パターンの参考情報 16
17. 誰とモデリングするか？ 17 • エンジニアだけではなく、ドメインエキスパートとモデリングすることが重要 • ドメインとは(おさらい)： ◦ ソフトウェアで問題解決しようとする領域 • ドメインエキスパートとは： ◦ 職種ではない ◦ 要は「ドメインに詳しい人」 ◦ それ以上でも以下でもない
18. ドメインエキスパートの必要性 • シンプルに、こう考えよう ◦ 「役に立つソフトウェアを作るために、現場を理解するために、 　 誰の知識が必要か？」 • 現場の知識があれば、必ず役立つものができる訳ではない しかし、現場の知識がないと役立つものが作れる可能性は下がる また、知識を得る頻度は多い方がよい • たまに聞かれる質問 「ドメインエキスパートがいないんですけどどうすればいいですか」 →「役立つものを作るのに十分な現場の知識を得るにはどうしたらいいか？」 　と考える 18
19. DDDにおけるモデリング手法 • DDDにおけるモデリング手法は具体的に定められているものはない • 今回は筆者が複数の現場でモデリングをしてきた中で、 最も導入ハードルが低く、効果を出しやすいと考えている手法を紹介します。 19
20. 以下の4つの図を使用したモデリング • システム関連図 • ユースケース図 • ドメインモデル図 • オブジェクト図 頭文字をとって「"sudo"モデリング」と覚えてください。 • 「必要最低限この4つは抑えると良い」というラインナップ • 他にも必要に応じて追加してください 状態遷移図、業務フロー図あたりは追加で作ることが多いです。 sudoモデリング 20
21. モデリングの題材 21
22. モデリングの題材 • モデリングの題材は、人事などの採用担当者が企業への応募者を管理する、 採用管理システムとします。 • システム開発初期のモデリングをシミュレーションしながら解説します。 22 応募者がたくさんいて、 管理が大変…！
23. アジェンダ • モデリングの必要性とDDDのアプローチ • モデリング方法 ◦ システム関連図 ◦ ユースケース図 ◦ ドメインモデル図 ◦ オブジェクト図 • モデルと実装のつながり • DDDのアーキテクチャ • DDDの実装パターンの参考情報 23
24. システム関連図 システム関連図は、開発するシステムと、 関わりのあるアクターや外部システムとの関連を示す図です。 24
25. 25 • 簡単な図のようですが、 この図を整理するためには次のような疑問に対して答えを出す必要があります。 ◦ これは誰が使うシステムなのか？ ◦ 開発するシステムで応募を直接受け付けるのか？
26. • モデリングの必要性とDDDのアプローチ • モデリング方法 ◦ システム関連図 ◦ ユースケース図 ◦ ドメインモデル図 ◦ オブジェクト図 • モデルと実装のつながり • DDDのアーキテクチャ • DDDの実装パターンの参考情報 アジェンダ 26
27. ユースケース図 ユースケース図は、ユーザーの要求に対するシステムの振る舞いを定義する図です。 27
28. このシステムのユースケースとしては多くのものが考えられますが、 まずはこのタイミングでのドメインモデル図作成の対象とするものを絞り込みます 28
29. アジェンダ • モデリングの必要性とDDDのアプローチ • モデリング方法 ◦ システム関連図 ◦ ユースケース図 ◦ ドメインモデル図 ◦ オブジェクト図 • モデルと実装のつながり • DDDのアーキテクチャ • DDDの実装パターンの参考情報 29
30. ドメインモデル図・オブジェクト図 • ドメインモデル図 ◦ 簡易化したクラス図のようなもの ◦ これが最終的にコードで表現される • オブジェクト図 ◦ ドメインモデルの具体的な値 ◦ 実際はこの具体値を書き出すところから始める • オブジェクト図での具体例の重要性 ◦ ここで具体例を書き出していくことが、モデリング参加者の認識を合わせ、発見 を生み出すために非常に重要。 ◦ 「具体例」は、実際の用途を理解する上で重要であるにもかかわらず、 クラス図にもテーブル定義にも表現されない情報 30
31. オブジェクト図 31
32. モデリングの際に重要なこと • ドメインに対する理解を深め、解決策を検討するのに役立つことは気軽に書く ◦ × 仕様書のようにきっちり ◦ ◦ ホワイトボードに板書する感覚、議事録を残す感覚 • 書くと良いこと ◦ 具体的な値 ◦ 疑問点や未決事項 ◦ そこからルール/制約を抽出していく 32
33. • オブジェクト図から、ドメインモデルに抽象化していく ◦ オブジェクトの代表的な属性を書く ◦ 「ルール/制約(ドメイン知識)」を吹き出しに書き出す ◦ オブジェクト同士の関連を示す ◦ 多重度を定義する • 実装前に細かく決めること ◦ 集約の範囲を定義する ◦ 日本語と英語の対訳を定義する ▪ これが「ユビキタス言語」のマスタになる ドメインモデル図・オブジェクト図 33
34. ルール/制約(①)：従うべきルールや制約を記載する。 モデリング中に疑問が出たものをその場で議論してメモしていく。 34
35. 検討メモ(②③) ：生じた疑問の結論や疑問点も記載してOK。 ドメインモデル図をもとに発見を誘発し、関係者の認識を残しておくために 必要なものは積極的に記述する。 35
36. 多重度(④) :オブジェクト間の多重度。細かいように見えるが、 「採用選考から採用ポジションを紐づけることは必須なのか？」など、 ルール/制約として重要な意思決定となる。 36
37. 実装前に主にエンジニアで議論して決めること 集約の範囲(⑤)、日本語名の対訳としての英語名(⑥) 37
38. • これらは実装よりの話なので、エンジニアだけで議論しても良い • 集約の範囲(⑤) ◦ 実装する際のリポジトリの範囲を決める ◦ 本資料末に参考資料を記載 • 日本語名の対訳としての英語名(⑥) ◦ これがユビキタス言語のマスタになる ▪ ユビキタス：in everywhereという意味で、 会話でも、画面でも、コードでもどこでも同じ用語で統一する ◦ ここで定義すると、エンドポイント名、テーブル名、クラス名などで使われる名称 の表記揺れを防ぐことができる 38
39. アジェンダ • モデリングの必要性とDDDのアプローチ • モデリング方法 • モデルと実装のつながり • DDDのアーキテクチャ • DDDの実装パターンの参考情報 39
40. モデルと実装のつながり • モデルを元に実装を行うが、ここでその形に乖離があると。。 • モデルに変更があった時、コードのどこに反映すべきかわからなくなる 40 どこに反映すれば良い ??
41. • モデルを元に実装を行うが、ここでその形に乖離があると。。 • モデルに変更があった時、コードのどこに反映すべきかわからなくなる • そのため、コードは極力モデルと同じ形での表現を目指す モデルと実装のつながり 41
42. • モデルをコードで表現するためのベストプラクティスが、 エンティティやリポジトリなどの実装パターン (極論、このパターンを使わなくても目的が達成できればOKです) • この実装パターンを適用するために、 アーキテクチャとしてレイヤーを整理する必要がある。 モデルと実装のつながり 42
43. アジェンダ • モデリングの必要性とDDDのアプローチ • モデリング方法 • モデルと実装のつながり • DDDのアーキテクチャ • DDDの実装パターンの参考情報 43
44. 3層アーキテクチャ • 最近はMVCやクリーンアーキテクチャの方がよく見るが、 以前はよく使われていたアーキテクチャ 44 プレゼンテーション層 ビジネスロジック層 データアクセス層 モデル
45. 3層アーキテクチャの問題 • 「ビジネスロジック層」がファットになりがち！！ 45 プレゼンテーション層 ビジネスロジック層 データアクセス層 モデル
46. 恐ろしいデジャヴ • みたことありませんか 46
47. 恐ろしいデジャヴ 47 • みたことありませんか ◦ XxxxService ◦ XxxxLogic ◦ という数百行、数千行の神クラスを・・・！ DoEverythingService
48. 恐ろしいデジャヴ 48 • みたことありませんか ◦ XxxxService ◦ XxxxLogic ◦ という数百行、数千行の神クラスを・・・！ DoEverythingService コードが追えない ちょっと触るとすぐバ グる 俗人化された 知見の嵐
49. 恐ろしいデジャヴ 49 • みたことありませんか ◦ XxxxService ◦ XxxxLogic ◦ という数百行、数千行の神クラスを・・・！ DoEverythingService コードが追えない ちょっと触るとすぐバ グる 俗人化された 知見の嵐
50. なぜこうなるのか 50
51. 実は、必然である 51
52. ・データベースとの入出力 • 層ごとの責務を整理すると・・・ 3層アーキテクチャの問題 52 ・クライアントとの入出力 ・ビジネスロジックの実現 プレゼンテーション層 ビジネスロジック層 データアクセス層 モデル ここに含まれるものが多すぎる
53. 「ビジネスロジック」 と、もう少し細かく向かい合う 53
54. タスク管理アプリケーションの例 • 企画の人から渡される「仕様」の例 ◦ ユーザー登録、非活性化ができる ◦ メールアドレスは重複登録できない ◦ タスク登録、更新、完了、未完了に戻す、延期、ユーザーへのアサインができる ◦ タスクは3 回までしか延期ができない ◦ 非活性化されていないユーザーにアサインができる ◦ タスク期日をカレンダーに登録することができる • いわゆる「仕様」「ビジネスロジック」 54
55. タスク管理アプリケーションの例 • 企画の人から渡される「仕様」の例 ◦ ユーザー登録、非活性化ができる ◦ メールアドレスは重複登録できない ◦ タスク登録、更新、完了、未完了に戻す、延期、ユーザーへのアサインができる ◦ タスクは3 回までしか延期ができない ◦ 非活性化されていないユーザーにアサインができる ◦ タスク期日をカレンダーに登録することができる • いわゆる「仕様」「ビジネスロジック」 • しかし、これらは本当に並列するべき同じ性質のものでしょうか？ 55
56. • このアプリケーションのユースケース図を整理すると ユースケース図を整理する 56
57. • このドメイン(ソフトウェアを適用して問題解決しようとする領域)に 存在するルール/制約を整理すると ルール/制約を整理する 57
58. 元の「仕様」にマッピングすると 58
59. • 企画の人から渡される「仕様」の例 ◦ ユーザー登録、非活性化ができる ◦ メールアドレスは重複登録できない ◦ タスク登録、更新、完了、未完了に戻す、延期、ユーザーへのアサインができる ◦ タスクは3 回までしか延期ができない ◦ 非活性化されていないユーザーにアサインができる ◦ タスク期日をカレンダーに登録することができる タスク管理アプリケーションの例 59 青字：ユースケース オレンジ字：ルール/制約
60. • 企画の人から渡される「仕様」の例 ◦ ユーザー登録、非活性化ができる ◦ メールアドレスは重複登録できない ◦ タスク登録、更新、完了、未完了に戻す、延期、ユーザーへのアサインができる ◦ タスクは3 回までしか延期ができない ◦ 非活性化されていないユーザーにアサインができる ◦ タスク期日をカレンダーに登録することができる タスク管理アプリケーションの例 青字：ユースケース オレンジ字：ルール/制約 60
61. • 企画の人から渡される「仕様」の例 ◦ ユーザー登録、非活性化ができる ◦ メールアドレスは重複登録できない ◦ タスク登録、更新、完了、未完了に戻す、延期、ユーザーへのアサインができる ◦ タスクは3 回までしか延期ができない ◦ 非活性化されていないユーザーにアサインができる ◦ タスク期日をカレンダーに登録することができる タスク管理アプリケーションの例 青字：ユースケース オレンジ字：ルール/制約 61
62. タスク管理アプリケーションの例 • 企画の人から渡される「仕様」の例 ◦ ユーザー登録、非活性化ができる ◦ メールアドレスは重複登録できない ◦ タスク登録、更新、完了、未完了に戻す、延期、ユーザーへのアサインができる ◦ タスクは3 回までしか延期ができない ◦ 非活性化されていないユーザーにアサインができる ◦ タスク期日をカレンダーに登録することができる • 異なる性質のものが全て「仕様」「ビジネスロジック」というくくりでまとめられてい た • ビジネスロジック層が責務過剰になり、凝集度が低下していた 青字：ユースケース オレンジ字：ルール/制約 62
63. ではどうするか 63
64. • 責務過剰なビジネスロジック層を・・・ 3層アーキテクチャの改善 64 ・データベースとの入出力 ・クライアントとの入出力 ・ユースケースの実現 プレゼンテーション層 ビジネスロジック層 データアクセス層 (インフラ層) ・ルール/制約 　(ドメイン知識)の実現
65. • 2種類の責務に合わせて2層に分割する！ 3層アーキテクチャの改善 65 ・データベースとの入出力 ・クライアントとの入出力 ・ユースケースの実現 プレゼンテーション層 ユースケース層 (アプリケーション層) データアクセス層 (インフラ層) ・ルール/制約 　(ドメイン知識)の実現 ドメイン層
66. • 2種類の責務に合わせて2層に分割する！ • これがEvans本で紹介される「レイヤードアーキテクチャ」 3層アーキテクチャの改善 66 ・データベースとの入出力 ・クライアントとの入出力 ・ユースケースの実現 プレゼンテーション層 ユースケース層 (アプリケーション層) データアクセス層 (インフラ層) ・ルール/制約 　(ドメイン知識)の実現 ドメイン層
67. レイヤードアーキテクチャの問題 • 問題 ◦ ドメイン層がインフラ層に依存している ▪ ドメイン層が特定のDBやライブラリに依存している ▪ DBやライブラリの実装によって、ドメイン層の実装に制限が生まれる ▪ 「ほんとはこうしたいんだけど、このORMだとどうしても・・・」 • 解決策 ◦ ドメイン層がインフラ層に依存しないようにしたい →どうやって？ →依存性の逆転を使用する 67
68. 3層アーキテクチャの改善 68 プレゼンテーショ ン層 ユースケース層 ドメイン層 インフラ層 プレゼンテーション層 ユースケース層 ドメイン層 インフラ層 実装クラス Interface プレゼンテー ション層 ユースケース層 ドメイン層 Interface インフラ層 実装クラス
69. DB、ORMの知識は ここに閉じ込める 3層アーキテクチャの改善 69 プレゼンテー ション層 ユースケース層 ドメイン層 インフラ層 ユースケース層、ドメイン層がDBやORMの知識を持たなくなった DB、ORMの知識を持たないので、 その影響を受けない実装が可能になる × × ×
70. • 最終的なアーキテクチャはこちら • あとはドメイン層に実装パターンを用いてモデルを表現する ユースケース層 ドメイン知識(ルール/制約)の実現 ドメインオブジェクトの実装 (エンティティ、値オブジェクト、 リポジトリのIF等) ドメイン層で定義されている IFの技術的詳細を提供 リポジトリ(実装クラス)の実装 ユースケースの実現 改善されたアーキテクチャ(オニオンアーキテクチャ) クライアントとの入出力 プレゼンテーショ ン層 ドメイン層 インフラ層 70
71. アジェンダ • モデリングの必要性とDDDのアプローチ • モデリング方法 • モデルと実装のつながり • DDDのアーキテクチャ • DDDの実装パターンの参考情報 71
72. 実装パターンの利用方法 • ドメイン層にて、ドメイン知識を表現するための実装パターン ◦ エンティティ ◦ 値オブジェクト ◦ リポジトリ ◦ ファクトリ ◦ ドメインサービス ◦ ドメインイベント • この実装方法については別の資料をご紹介します 72
73. 実装方法についてはこちらをご覧ください 73 • YouTube動画「10分DDD」シリーズ https://www.youtube.com/watch?v=Upeg6cNOirc https://www.youtube.com/watch?v=Hn4EAXYBl8c 動画で使用しているテキスト資料も公開しています(動画概要欄より)
74. 入門本2冊 74 • ドメイン駆動設計モデリング/実装ガイド ◦ DDDの基礎的な概念から実装パターンまで基礎知識を解説 • ドメイン駆動設計サンプルコード&FAQ ◦ 実装時に突き当たる課題をサンプルコードをふんだんに盛り込んで解説 ◦ 「モデリング」「集約」「テスト」について詳細解説
75. querie.me • 匿名で質問受け付けています https://querie.me/user/little_hand_s 75
76. リンクにURLがまとまっています https://little-hand-s.notion.site/Online-Conference-f545338e5b4d 4855a78b28adc1395ffb?pvs=74 76
77. ご静聴ありがとうございました 77