Tweet
Tweet

Slide 1

Slide 1 text

松岡 幸一郎 (@little_hand_s) 2024/5/22 事業価値を生み出すモデリング 価値をサステナブルにするアーキテクチャ 1

Slide 2

Slide 2 text

● 名前 ○ 松岡 幸一郎 (@little_hand_s) ● 所属 ○ 株式会社ログラス 経営管理領域でDDDを実践中 ● 発信 ○ 「ドメイン駆動設計 サンプルコード＆FAQ」 「ドメイン駆動設計 モデリング/実装ガイド」執筆 ○ 質問箱 (DDD関連の匿名質問受付) ○ DDD関連の技術ブログ ○ Youtube DDD解説動画チャンネル ● その他活動 ○ 企業様へのDDD導入/設計サポートなど 自己紹介 2

Slide 3

Slide 3 text

● 日本アイ・ビー・エム ○ 金融機関のお客様でミッションクリティカルなシステム開発 ● ビズリーチ ○ レガシーコードとの戦いの中で、アジャイル開発の手法と出会う ■ スクラム、エクストリームプログラミング、テスト駆動開発 ○ 新規プロジェクトでドメイン駆動設計の開発 ● ログラス ○ アジャイル、DDDを開発組織全体に浸透 経歴 3

Slide 4

Slide 4 text

4 ©2024 Loglass Inc. 企業価値を向上する 経営管理クラウド

Slide 5

Slide 5 text

5 ログラスProductTeam公式Xはじまりました！ https://twitter.com/LoglassPrdTeam

Slide 6

Slide 6 text

● ドメイン駆動設計の手法を用いて、 モデリングで機能性を高め、 アーキテクチャと実装パターンで保守性を高める方法を紹介します。 ● 機能性→事業価値を高める ● 保守性→開発をサステイナブルにする 本日のお話 6

Slide 7

Slide 7 text

アジェンダ ● モデリングの必要性とDDDのアプローチ ● モデリング方法 ● モデルと実装のつながり ● DDDのアーキテクチャ ● DDDの実装パターンの参考情報 7

Slide 8

Slide 8 text

● ソフトウェアはなんのために作るのか？ 8

Slide 9

Slide 9 text

● ソフトウェアを適用する対象の何らかの問題を解決するため 9

Slide 10

Slide 10 text

● ドメイン駆動設計の文脈では、 この「ソフトウェアで問題解決しようとする対象」を「ドメイン」と呼ぶ 10

Slide 11

Slide 11 text

DDDの言葉の定義を確認 DDD Reference: DomainLanguage.comにあるDDDのエッセンスの要約版 Evans本よりだいぶまとまっているので、定義などに迷ったらまずこちらを参考に 11

Slide 12

Slide 12 text

DDDとは ● DDD： DomainDrivenDesign(ドメイン駆動設計)の略 ● DDD Referenceより "多くのプロジェクトは、モデリングを行っても 最終的に大きな利益を得られないまま終わります。 DDDは、モデリングから劇的な利益を得られたプロジェクトから、 成功するパターンを抽出します。” 12

Slide 13

Slide 13 text

DDDとは ● DDD： DomainDrivenDesign(ドメイン駆動設計)の略 ● DDD Referenceより "多くのプロジェクトは、モデリングを行っても 最終的に大きな利益を得られないまま終わります。 DDDは、モデリングから劇的な利益を得られたプロジェクトから、 成功するパターンを抽出します。” 13

Slide 14

Slide 14 text

● ①ソフトウェアの機能性を高めること → 役に立つものを作る 　「作ったけど使えない」を避ける ● ②ソフトウェアの保守性を高めること → 長期間開発しても機能拡張が容易でありつづける 　 「技術的負債でどんどん開発速度が低下する」を避ける DDDでは 役に立つソフトウェアを、長期間保守性を下げずに作り続けられるようにする ことを目指します DDDの目的 14

Slide 15

Slide 15 text

● ①機能性向上へのアプローチ → ドメインエキスパートと共に行うドメインモデリング ○ 「ドメインモデル」という抽象化物にドメインの知識を反映することで、 役に立つものになる可能性を高める ○ 開発初期だけではなく、各フェーズで得られた発見をこまめに フィードバックすることで改善頻度を上げる ● ②保守性向上のためのアプローチ → 頻繁なモデルの更新に耐えられる実装パターンとアーキテクチャ ○ モデルの形をそのままコードで表現し、モデルの変更を反映しやすくする ○ 頻繁な更新に耐えられるように、 保守性の高いデザインパターン(エンティティ、リポジトリ等)を適用する ○ そのパターンを実現しやすいアーキテクチャを活用する DDDのアプローチ(1/2) 15

Slide 16

Slide 16 text

アジェンダ ● モデリングの必要性とDDDのアプローチ ● モデリング方法 ● モデルと実装のつながり ● DDDのアーキテクチャ ● DDDの実装パターンの参考情報 16

Slide 17

Slide 17 text

誰とモデリングするか？ 17 ● エンジニアだけではなく、ドメインエキスパートとモデリングすることが重要 ● ドメインとは(おさらい)： ○ ソフトウェアで問題解決しようとする領域 ● ドメインエキスパートとは： ○ 職種ではない ○ 要は「ドメインに詳しい人」 ○ それ以上でも以下でもない

Slide 18

Slide 18 text

ドメインエキスパートの必要性 ● シンプルに、こう考えよう ○ 「役に立つソフトウェアを作るために、現場を理解するために、 　 誰の知識が必要か？」 ● 現場の知識があれば、必ず役立つものができる訳ではない しかし、現場の知識がないと役立つものが作れる可能性は下がる また、知識を得る頻度は多い方がよい ● たまに聞かれる質問 「ドメインエキスパートがいないんですけどどうすればいいですか」 →「役立つものを作るのに十分な現場の知識を得るにはどうしたらいいか？」 　と考える 18

Slide 19

Slide 19 text

DDDにおけるモデリング手法 ● DDDにおけるモデリング手法は具体的に定められているものはない ● 今回は筆者が複数の現場でモデリングをしてきた中で、 最も導入ハードルが低く、効果を出しやすいと考えている手法を紹介します。 19

Slide 20

Slide 20 text

以下の4つの図を使用したモデリング ● システム関連図 ● ユースケース図 ● ドメインモデル図 ● オブジェクト図 頭文字をとって「"sudo"モデリング」と覚えてください。 ● 「必要最低限この4つは抑えると良い」というラインナップ ● 他にも必要に応じて追加してください 状態遷移図、業務フロー図あたりは追加で作ることが多いです。 sudoモデリング 20

Slide 21

Slide 21 text

モデリングの題材 21

Slide 22

Slide 22 text

モデリングの題材 ● モデリングの題材は、人事などの採用担当者が企業への応募者を管理する、 採用管理システムとします。 ● システム開発初期のモデリングをシミュレーションしながら解説します。 22 応募者がたくさんいて、 管理が大変…！

Slide 23

Slide 23 text

アジェンダ ● モデリングの必要性とDDDのアプローチ ● モデリング方法 ○ システム関連図 ○ ユースケース図 ○ ドメインモデル図 ○ オブジェクト図 ● モデルと実装のつながり ● DDDのアーキテクチャ ● DDDの実装パターンの参考情報 23

Slide 24

Slide 24 text

システム関連図 システム関連図は、開発するシステムと、 関わりのあるアクターや外部システムとの関連を示す図です。 24

Slide 25

Slide 25 text

25 ● 簡単な図のようですが、 この図を整理するためには次のような疑問に対して答えを出す必要があります。 ○ これは誰が使うシステムなのか？ ○ 開発するシステムで応募を直接受け付けるのか？

Slide 26

Slide 26 text

● モデリングの必要性とDDDのアプローチ ● モデリング方法 ○ システム関連図 ○ ユースケース図 ○ ドメインモデル図 ○ オブジェクト図 ● モデルと実装のつながり ● DDDのアーキテクチャ ● DDDの実装パターンの参考情報 アジェンダ 26

Slide 27

Slide 27 text

ユースケース図 ユースケース図は、ユーザーの要求に対するシステムの振る舞いを定義する図です。 27

Slide 28

Slide 28 text

このシステムのユースケースとしては多くのものが考えられますが、 まずはこのタイミングでのドメインモデル図作成の対象とするものを絞り込みます 28

Slide 29

Slide 29 text

アジェンダ ● モデリングの必要性とDDDのアプローチ ● モデリング方法 ○ システム関連図 ○ ユースケース図 ○ ドメインモデル図 ○ オブジェクト図 ● モデルと実装のつながり ● DDDのアーキテクチャ ● DDDの実装パターンの参考情報 29

Slide 30

Slide 30 text

ドメインモデル図・オブジェクト図 ● ドメインモデル図 ○ 簡易化したクラス図のようなもの ○ これが最終的にコードで表現される ● オブジェクト図 ○ ドメインモデルの具体的な値 ○ 実際はこの具体値を書き出すところから始める ● オブジェクト図での具体例の重要性 ○ ここで具体例を書き出していくことが、モデリング参加者の認識を合わせ、発見 を生み出すために非常に重要。 ○ 「具体例」は、実際の用途を理解する上で重要であるにもかかわらず、 クラス図にもテーブル定義にも表現されない情報 30

Slide 31

Slide 31 text

オブジェクト図 31

Slide 32

Slide 32 text

モデリングの際に重要なこと ● ドメインに対する理解を深め、解決策を検討するのに役立つことは気軽に書く ○ × 仕様書のようにきっちり ○ ○ ホワイトボードに板書する感覚、議事録を残す感覚 ● 書くと良いこと ○ 具体的な値 ○ 疑問点や未決事項 ○ そこからルール/制約を抽出していく 32

Slide 33

Slide 33 text

● オブジェクト図から、ドメインモデルに抽象化していく ○ オブジェクトの代表的な属性を書く ○ 「ルール/制約(ドメイン知識)」を吹き出しに書き出す ○ オブジェクト同士の関連を示す ○ 多重度を定義する ● 実装前に細かく決めること ○ 集約の範囲を定義する ○ 日本語と英語の対訳を定義する ■ これが「ユビキタス言語」のマスタになる ドメインモデル図・オブジェクト図 33

Slide 34

Slide 34 text

ルール/制約(①)：従うべきルールや制約を記載する。 モデリング中に疑問が出たものをその場で議論してメモしていく。 34

Slide 35

Slide 35 text

検討メモ(②③) ：生じた疑問の結論や疑問点も記載してOK。 ドメインモデル図をもとに発見を誘発し、関係者の認識を残しておくために 必要なものは積極的に記述する。 35

Slide 36

Slide 36 text

多重度(④) :オブジェクト間の多重度。細かいように見えるが、 「採用選考から採用ポジションを紐づけることは必須なのか？」など、 ルール/制約として重要な意思決定となる。 36

Slide 37

Slide 37 text

実装前に主にエンジニアで議論して決めること 集約の範囲(⑤)、日本語名の対訳としての英語名(⑥) 37

Slide 38

Slide 38 text

● これらは実装よりの話なので、エンジニアだけで議論しても良い ● 集約の範囲(⑤) ○ 実装する際のリポジトリの範囲を決める ○ 本資料末に参考資料を記載 ● 日本語名の対訳としての英語名(⑥) ○ これがユビキタス言語のマスタになる ■ ユビキタス：in everywhereという意味で、 会話でも、画面でも、コードでもどこでも同じ用語で統一する ○ ここで定義すると、エンドポイント名、テーブル名、クラス名などで使われる名称 の表記揺れを防ぐことができる 38

Slide 39

Slide 39 text

アジェンダ ● モデリングの必要性とDDDのアプローチ ● モデリング方法 ● モデルと実装のつながり ● DDDのアーキテクチャ ● DDDの実装パターンの参考情報 39

Slide 40

Slide 40 text

モデルと実装のつながり ● モデルを元に実装を行うが、ここでその形に乖離があると。。 ● モデルに変更があった時、コードのどこに反映すべきかわからなくなる 40 どこに反映すれば良い ??

Slide 41

Slide 41 text

● モデルを元に実装を行うが、ここでその形に乖離があると。。 ● モデルに変更があった時、コードのどこに反映すべきかわからなくなる ● そのため、コードは極力モデルと同じ形での表現を目指す モデルと実装のつながり 41

Slide 42

Slide 42 text

● モデルをコードで表現するためのベストプラクティスが、 エンティティやリポジトリなどの実装パターン (極論、このパターンを使わなくても目的が達成できればOKです) ● この実装パターンを適用するために、 アーキテクチャとしてレイヤーを整理する必要がある。 モデルと実装のつながり 42

Slide 43

Slide 43 text

アジェンダ ● モデリングの必要性とDDDのアプローチ ● モデリング方法 ● モデルと実装のつながり ● DDDのアーキテクチャ ● DDDの実装パターンの参考情報 43

Slide 44

Slide 44 text

3層アーキテクチャ ● 最近はMVCやクリーンアーキテクチャの方がよく見るが、 以前はよく使われていたアーキテクチャ 44 プレゼンテーション層 ビジネスロジック層 データアクセス層 モデル

Slide 45

Slide 45 text

3層アーキテクチャの問題 ● 「ビジネスロジック層」がファットになりがち！！ 45 プレゼンテーション層 ビジネスロジック層 データアクセス層 モデル

Slide 46

Slide 46 text

恐ろしいデジャヴ ● みたことありませんか 46

Slide 47

Slide 47 text

恐ろしいデジャヴ 47 ● みたことありませんか ○ XxxxService ○ XxxxLogic ○ という数百行、数千行の神クラスを・・・！ DoEverythingService

Slide 48

Slide 48 text

恐ろしいデジャヴ 48 ● みたことありませんか ○ XxxxService ○ XxxxLogic ○ という数百行、数千行の神クラスを・・・！ DoEverythingService コードが追えない ちょっと触るとすぐバ グる 俗人化された 知見の嵐

Slide 49

Slide 49 text

恐ろしいデジャヴ 49 ● みたことありませんか ○ XxxxService ○ XxxxLogic ○ という数百行、数千行の神クラスを・・・！ DoEverythingService コードが追えない ちょっと触るとすぐバ グる 俗人化された 知見の嵐

Slide 50

Slide 50 text

なぜこうなるのか 50

Slide 51

Slide 51 text

実は、必然である 51

Slide 52

Slide 52 text

・データベースとの入出力 ● 層ごとの責務を整理すると・・・ 3層アーキテクチャの問題 52 ・クライアントとの入出力 ・ビジネスロジックの実現 プレゼンテーション層 ビジネスロジック層 データアクセス層 モデル ここに含まれるものが多すぎる

Slide 53

Slide 53 text

「ビジネスロジック」 と、もう少し細かく向かい合う 53

Slide 54

Slide 54 text

タスク管理アプリケーションの例 ● 企画の人から渡される「仕様」の例 ○ ユーザー登録、非活性化ができる ○ メールアドレスは重複登録できない ○ タスク登録、更新、完了、未完了に戻す、延期、ユーザーへのアサインができる ○ タスクは3 回までしか延期ができない ○ 非活性化されていないユーザーにアサインができる ○ タスク期日をカレンダーに登録することができる ● いわゆる「仕様」「ビジネスロジック」 54

Slide 55

Slide 55 text

タスク管理アプリケーションの例 ● 企画の人から渡される「仕様」の例 ○ ユーザー登録、非活性化ができる ○ メールアドレスは重複登録できない ○ タスク登録、更新、完了、未完了に戻す、延期、ユーザーへのアサインができる ○ タスクは3 回までしか延期ができない ○ 非活性化されていないユーザーにアサインができる ○ タスク期日をカレンダーに登録することができる ● いわゆる「仕様」「ビジネスロジック」 ● しかし、これらは本当に並列するべき同じ性質のものでしょうか？ 55

Slide 56

Slide 56 text

● このアプリケーションのユースケース図を整理すると ユースケース図を整理する 56

Slide 57

Slide 57 text

● このドメイン(ソフトウェアを適用して問題解決しようとする領域)に 存在するルール/制約を整理すると ルール/制約を整理する 57

Slide 58

Slide 58 text

元の「仕様」にマッピングすると 58

Slide 59

Slide 59 text

● 企画の人から渡される「仕様」の例 ○ ユーザー登録、非活性化ができる ○ メールアドレスは重複登録できない ○ タスク登録、更新、完了、未完了に戻す、延期、ユーザーへのアサインができる ○ タスクは3 回までしか延期ができない ○ 非活性化されていないユーザーにアサインができる ○ タスク期日をカレンダーに登録することができる タスク管理アプリケーションの例 59 青字：ユースケース オレンジ字：ルール/制約

Slide 60

Slide 60 text

● 企画の人から渡される「仕様」の例 ○ ユーザー登録、非活性化ができる ○ メールアドレスは重複登録できない ○ タスク登録、更新、完了、未完了に戻す、延期、ユーザーへのアサインができる ○ タスクは3 回までしか延期ができない ○ 非活性化されていないユーザーにアサインができる ○ タスク期日をカレンダーに登録することができる タスク管理アプリケーションの例 青字：ユースケース オレンジ字：ルール/制約 60

Slide 61

Slide 61 text

● 企画の人から渡される「仕様」の例 ○ ユーザー登録、非活性化ができる ○ メールアドレスは重複登録できない ○ タスク登録、更新、完了、未完了に戻す、延期、ユーザーへのアサインができる ○ タスクは3 回までしか延期ができない ○ 非活性化されていないユーザーにアサインができる ○ タスク期日をカレンダーに登録することができる タスク管理アプリケーションの例 青字：ユースケース オレンジ字：ルール/制約 61

Slide 62

Slide 62 text

タスク管理アプリケーションの例 ● 企画の人から渡される「仕様」の例 ○ ユーザー登録、非活性化ができる ○ メールアドレスは重複登録できない ○ タスク登録、更新、完了、未完了に戻す、延期、ユーザーへのアサインができる ○ タスクは3 回までしか延期ができない ○ 非活性化されていないユーザーにアサインができる ○ タスク期日をカレンダーに登録することができる ● 異なる性質のものが全て「仕様」「ビジネスロジック」というくくりでまとめられてい た ● ビジネスロジック層が責務過剰になり、凝集度が低下していた 青字：ユースケース オレンジ字：ルール/制約 62

Slide 63

Slide 63 text

ではどうするか 63

Slide 64

Slide 64 text

● 責務過剰なビジネスロジック層を・・・ 3層アーキテクチャの改善 64 ・データベースとの入出力 ・クライアントとの入出力 ・ユースケースの実現 プレゼンテーション層 ビジネスロジック層 データアクセス層 (インフラ層) ・ルール/制約 　(ドメイン知識)の実現

Slide 65

Slide 65 text

● 2種類の責務に合わせて2層に分割する！ 3層アーキテクチャの改善 65 ・データベースとの入出力 ・クライアントとの入出力 ・ユースケースの実現 プレゼンテーション層 ユースケース層 (アプリケーション層) データアクセス層 (インフラ層) ・ルール/制約 　(ドメイン知識)の実現 ドメイン層

Slide 66

Slide 66 text

● 2種類の責務に合わせて2層に分割する！ ● これがEvans本で紹介される「レイヤードアーキテクチャ」 3層アーキテクチャの改善 66 ・データベースとの入出力 ・クライアントとの入出力 ・ユースケースの実現 プレゼンテーション層 ユースケース層 (アプリケーション層) データアクセス層 (インフラ層) ・ルール/制約 　(ドメイン知識)の実現 ドメイン層

Slide 67

Slide 67 text

レイヤードアーキテクチャの問題 ● 問題 ○ ドメイン層がインフラ層に依存している ■ ドメイン層が特定のDBやライブラリに依存している ■ DBやライブラリの実装によって、ドメイン層の実装に制限が生まれる ■ 「ほんとはこうしたいんだけど、このORMだとどうしても・・・」 ● 解決策 ○ ドメイン層がインフラ層に依存しないようにしたい →どうやって？ →依存性の逆転を使用する 67

Slide 68

Slide 68 text

3層アーキテクチャの改善 68 プレゼンテーショ ン層 ユースケース層 ドメイン層 インフラ層 プレゼンテーション層 ユースケース層 ドメイン層 インフラ層 実装クラス Interface プレゼンテー ション層 ユースケース層 ドメイン層 Interface インフラ層 実装クラス

Slide 69

Slide 69 text

DB、ORMの知識は ここに閉じ込める 3層アーキテクチャの改善 69 プレゼンテー ション層 ユースケース層 ドメイン層 インフラ層 ユースケース層、ドメイン層がDBやORMの知識を持たなくなった DB、ORMの知識を持たないので、 その影響を受けない実装が可能になる × × ×

Slide 70

Slide 70 text

● 最終的なアーキテクチャはこちら ● あとはドメイン層に実装パターンを用いてモデルを表現する ユースケース層 ドメイン知識(ルール/制約)の実現 ドメインオブジェクトの実装 (エンティティ、値オブジェクト、 リポジトリのIF等) ドメイン層で定義されている IFの技術的詳細を提供 リポジトリ(実装クラス)の実装 ユースケースの実現 改善されたアーキテクチャ(オニオンアーキテクチャ) クライアントとの入出力 プレゼンテーショ ン層 ドメイン層 インフラ層 70

Slide 71

Slide 71 text

アジェンダ ● モデリングの必要性とDDDのアプローチ ● モデリング方法 ● モデルと実装のつながり ● DDDのアーキテクチャ ● DDDの実装パターンの参考情報 71

Slide 72

Slide 72 text

実装パターンの利用方法 ● ドメイン層にて、ドメイン知識を表現するための実装パターン ○ エンティティ ○ 値オブジェクト ○ リポジトリ ○ ファクトリ ○ ドメインサービス ○ ドメインイベント ● この実装方法については別の資料をご紹介します 72

Slide 73

Slide 73 text

実装方法についてはこちらをご覧ください 73 ● YouTube動画「10分DDD」シリーズ https://www.youtube.com/watch?v=Upeg6cNOirc https://www.youtube.com/watch?v=Hn4EAXYBl8c 動画で使用しているテキスト資料も公開しています(動画概要欄より)

Slide 74

Slide 74 text

入門本2冊 74 ● ドメイン駆動設計モデリング/実装ガイド ○ DDDの基礎的な概念から実装パターンまで基礎知識を解説 ● ドメイン駆動設計サンプルコード&FAQ ○ 実装時に突き当たる課題をサンプルコードをふんだんに盛り込んで解説 ○ 「モデリング」「集約」「テスト」について詳細解説

Slide 75

Slide 75 text

querie.me ● 匿名で質問受け付けています https://querie.me/user/little_hand_s 75

Slide 76

Slide 76 text

リンクにURLがまとまっています https://little-hand-s.notion.site/Online-Conference-f545338e5b4d 4855a78b28adc1395ffb?pvs=74 76

Slide 77

Slide 77 text

ご静聴ありがとうございました 77