新説 ドメイン駆動開発 ~ DDD & LLM (1)

本記事は 新説 ドメイン駆動開発 の連載記事の1つです.
連載記事の一覧は こちら .

概要

LLM(大規模言語モデル) と DDD(ドメイン駆動設計/開発) との関係について既存の議論を調査した上で考察.
特に LM for DDD (DDDにLMがどう寄与しうるか) の部分を掘り下げて整理.

はじめに

本記事では LM(言語モデル)によるソフトウェア開発 と DDD(ドメイン駆動設計/開発) との関係性について考察する.

以下の3つの観点で考察してみようと思う.

1. LM for DDD ← 本記事は主にこの部分がテーマ
2. DDD for LM
3. DDD for LM-aided Software Engineering

1はLMをDDDに活用することを指す. 新説 ドメイン駆動開発 ~ 序 ではLMをドメインモデルの作成などに活用できる可能性があることを述べたが, これは LM for DDD に該当する.

2はLM開発にDDDを適用することを指す. これは基本的にはMLモデルの開発にドメイン駆動開発の方法論やドメインモデルがいかに活用できるか, という話なので, DDD for ML の一環として考察しようと思う. 例えば, LMがどの範囲のドメインやサブドメインまで対応しうるかを明確化し, その範囲内で品質を保証するために(または, その範囲外では回答を控えることを保証するために)ドメインモデルを活用する, などの観点で考察ができるだろう.

3はLMを活用したソフトウェア開発にDDDの思想を取り入れ, 実践することを指す. ChatGPTの台頭以後, 業界でソフトウェア開発をLMで自動化・効率化を図る動きが活発化しており, MetaGPT や Devin, AutoDev などをはじめとして, その分野の技術が日進月歩で進化している. 簡単なアプリなら一切コーディングしなくても要望を伝えるだけでAI(たち)がそれをつくってくれる, みたいな話も出てきている. コンピュータを利用したソフトウェア開発は Computer-aided Software Engineering (CASE) と呼ばれているが, このようにAIやLMを利用した場合は, AI-aided Software Enginnering (AIASE) や LM-aided Software Engineering (LMASE) と呼べるだろう. もはや補助(aid)を超えて開発の主役をLMが担う可能性もある. 極端な話だが, 要件や仕様を入れればいきなりコードが生成されるという世界が来たとき, DDDは必要になるのか, という疑問も出てくる. ここでは, LMASEにおいてDDDはそもそも必要になるのか, DDDはどのような価値を提供し, どのような役割を果たしうるか, を考察しようと思う.

本記事では特に1の "LM for DDD" のテーマを掘り下げて考察する.

既存の議論 [2024/5時点]

既にある議論の後追いにならないためにも, まずは調査.

DDDコミュニティの動向

まず, DDDのコミュニティではLMはどのように受け入れられているのだろうか..
2024年3月に開催された Explore DDD Conference ではDDDの開祖たる Evans が "DDD and LLMs" というテーマで基調講演を行っている [Youtube]. カンファレンスの議論の内容を以下にまとめる.

• Evans は "システムやその開発にLLMを取り入れる革新的な道を探すべき" と述べており, 肯定的な意見.
  • LLMについて学び, 実験し, その知見をコミュニティと共有することを呼びかけている.
  • 複雑なシステム開発の一部は人間が担い, 一部はLLMが担うようになる可能性がある.
  • ドメインに特化して訓練されたLLMの有用性に期待.
  • 自然言語を入力としてそれが設計に組み込まれるような世界が近いうちにくることを予想.
• 一方でLLMの利用に対して懐疑的な意見もあり.
  • LLMによる開発は計算コストや金銭的なコストが高くなる可能性があり.
    • これに対して, Evans は今後タスク特化型の低コストな小規模なLMが提供される可能性を示唆.

研究論文の動向

次に, 研究論文で LM と DDD の関係について述べているものがないか調べてみた.
Google Scholar で "domain-driven (design)" "(large) language model" で調べてみると数十件の論文がヒットするものの, 知識獲得や語彙抽出¹, 知識蒸留², ドメインモデルの生成³ など部分的な取組みに関する研究がほとんどで, LM と DDD の関係について包括的に整理されたものは見つからなかった.

LM for DDD

現時点で LM と DDD の関係性について包括的に整理したものはあまりなさそうだったので, 自分なりに整理してみようと思う.

LM for DDD のユースケースしてはDDDのタスクに対応させて考えると, 主要なものとしては以下の2つがありそう.

1. LMを用いてドメインモデルを開発する (DM Development)
2. LMを用いてドメインモデル等を基に工程成果物を開発する (DM-to-X).

DM Development には, LMが学習して内部に蓄積している知識からドメインモデルを作ることや, その元となるドメイン知識を引き出すこと, または, LMの推論能力や検索能力を利用してコーパス(ドメイン固有の文書データ群)からドメイン知識を抽出すること, などが含まれる. これによりドメインモデルの開発を自動化(省人化)できる可能性がある. それがコスト削減や効率化につながるかについては既存の議論でも話があったが, 結局はLMの性能やコスト次第なところがありそう. その他の課題としては, LMがドメインモデルを生成したときにその良さ(正確性, 合目的性など)をどのように評価するか, などが挙げられそう.

DM-to-X には, ドメインモデルを(場合によっては他のコンテキストデータと共に)LMの入力として, 要求仕様や設計図, コードなどの工程成果物を生成させることが含まれる. 自動化(省人化)やコスト削減, 効率化については上と同様.

上記のユースケースでLMから低コストに適切な出力を得るためには, LMを訓練し, ドメイン固有の用語法や記述スタイルに適合させ, かつ, ドメイン知識を習得させることが必要になる場合もある.
また, 利用するモデルが独自に訓練したものであるか(ChatGPTなどの)既存のものであるかに関わらず, LMを利用する際にはモデルの能力を把握しておくことが望ましい. 特に上記の2つのタスクに適用するにあたって十分な能力があるかを把握しておくことが重要となる. 例えば, 必要なドメイン知識が習得できているかなどを検証する, など.

その他, LMを開発者のドメイン知識やDDDの習得支援に利用するユースケースもありそう.

上記を踏まえて LM for DDD の活動の全体像をまとめてみた. データ工学, モデル実装, モデル評価, (ソフトウェア開発への)モデル活用 というMLモデルの開発の工程に沿った形で整理してみた(一応 ISO/IEC 5338 のプロセスに寄せてはいる).

以下の節ではこの図の枠組みに基づいてそれぞれの活動について記述する.

知識&データ工学 (Knowledge & Data Engineering)

この工程ではLMの学習やテスト, 推論に利用するデータを整備する. データには対象のドメインのテキストデータを集めたコーパスやドメインモデルが含まれ, これらの作成や洗練が主な活動となる.

Domain Modeling

ドメインモデリングはドメイン知識の獲得, それらの知識の形式化・構造化, できあがったモデルのレビュー・検証, 統合・マッピング, 保守などのタスクから構成される.
この活動の成果物としてドメインモデルが得られる. ドメインモデルはDDDの中核をなすものであり, LM4DDDの活動の中でも特に重要といえる. ドメインモデルは対象とするドメインの 概念 や 概念間の関係性, ルール などをモデル化したものであり, 典型的にはUMLのクラス図で表現されるが, OWLなどのオントロジ記述言語で表現される場合もある.

LMの活用方法としては以下のようなものが考えられる.

• LMが学習して内部に蓄積している知識から(いきなり)ドメインモデルを生成させる.
  *plantuml や OWL/Turtle などのテキスト記法でモデルを記述させることを想定.
• LMが学習して内部に蓄積している知識からドメインモデルの元となる概念やルールなどをリストアップさせる.
• LMにコーパスのデータを与え, ドメインモデルの元となる概念やルールなどを抜き出させる.
• LMに上記のリストアップした概念を構造化させ, ドメインモデルを生成させる.
• LMにできあがったドメインモデルをレビューさせる.
• LMに複数のドメインモデルを統合させる.
• LMに複数のドメインモデルの概念のマッピングを行わせる (コンテキストマッピング).
• ドメインエキスパートの役割を与えたLMチャットボットを作成し, 開発者がそれにヒアリングすることでドメイン知識の獲得や確認を行う.
  　*コーパスのデータを与え, RAGなどの仕組みを活用して回答させることも考えられる.

ドメイン知識の抽出やドメインモデルの生成は, 先述の研究 ^{1 2 3} などで取り扱われており, いくつか実例がある. なお, ドメインのコーパスで訓練したLMから, 訓練で蓄積した知識を取り出す過程は蒸留に相当すると考えられる. また, OWL/Turtle の形式はいわゆるナレッジグラフ(Knowledge Graph; KG)であり, LMをKGと組み合わせる研究 ^{4 5} もこの活動に関連する.
複数のLMのエージェントを組み合せてマルチエージェントで協調してソフトウェア開発を行うためのフレームワーク (MetaGPT, AutoGenなど) もあり, それを用いてこれらのタスクを行わせることも考えられる.

Corpus (Data) Refinement

コーパスデータの洗練はコーパスデータの品質保証を図るための活動を指す. コーパスのデータはLMの訓練データやテストデータ, 推論時のコンテキストデータとして用いられ, すべてのドメイン知識の源泉となる(学習済みモデルを利用する場合にはLMにもともと蓄積されている知識が追加される). このデータの品質(記述内容の正当性や表記の一貫性など)の保証はLMの出力の精度向上に寄与すると考えられる. コーパスのデータはDDDで直接的に必要となるものではないが, LMでドメインモデルや工程成果物を作成する上での基礎となるため, このデータの洗練も重要といえるだろう.

LMの活用方法としては以下のようなものが考えられる.

• LMにコーパスのテキストをドメインモデルに含まれる共通語彙で書き換えさせる.
• LMにコーパスのテキストをドメインモデルに含まれるルールと照らし合わせて不適切な記述を検出する.

モデル実装 (Model Implementation)

モデル実装にはLMのモデルの選定・設計や訓練データセットの設計, モデルの訓練方法の決定, 訓練の実施が含まれる. モデル実装はLM4DDDで必ずしも必要となるわけではなく, 既存のLMを利用することもできるが, 先に述べたようにドメインモデルや工程成果物の作成のタスクにおいて, LMから低コストで適切な出力を得るためには, 訓練されたLMが必要になる場合がある.

LM4DDDのタスクに向けたLMの学習方法としては様々なものが考えられるが, 典型的な例を以下に挙げる. これらの組合せも可能.

• Self-Supervised Training
  • 対象ドメインのコーパスを訓練データとして用いて, CLM(Causal Language Modeling) によりLMの事前学習(Pre-training)を行う.
• Supervised Training
  • 質問応答やテキスト分類, 要約, 翻訳(プログラミング言語間のトランスパイル含む), などのタスクの訓練データのコンテキストにドメインモデルのデータを埋め込み, Supervised Fine Tuning (SFT) / Instrunction Tuning (IT) を行う.
  • ドメインモデルの作成やレビュー, ドメインモデルからのDBスキーマやJSONスキーマ, オブジェクト指向プログラミング言語のコード生成, などのDDDのタスクで SFT / IT を行う.
• Reinforcement Learning
  • 上記の SFT で訓練されたLMに複数の回答を出力させ, どの回答が優れているかの選好ラベルをつけて, 選好ラベルに基づいて報酬モデルを学習し, 報酬モデルを利用して強化学習を行う (Reinforcement Learning with Human Feedback; RLHF).

なお, ChatGPTではファインチューニングの方法がSFTに限定されている. 利用するサービスに応じてサポートされている学習方法を選択することや, 逆に望ましい学習方法に応じてサービスを選択することが必要になることもある.

モデル評価 (Model V&V)

モデル評価には評価データセットの設計やモデルの評価方法の決定, 評価(テスト)の実施が含まれる. モデル評価もLM4DDDで必ずしも必要となるわけではないが, 先に述べたように, 利用するモデルが独自に訓練したものであるか既存のものであるかに関わらず,ドメインモデルや工程成果物の作成のタスクにおいて, 十分な能力があるか把握しておくことが望ましい.

LM4DDDのタスクに向けたLMの評価方法としては以下のようなものが考えられる.

• Open-book QA のタスクでドメイン固有の文章の読解力が十分にあるか評価する.
• Closed-book QA のタスクでドメインの知識が十分に習得できるか評価する.
• ドメインモデルの作成やレビュー, ドメインモデルからのドメインモデルからのDBスキーマやJSONスキーマ, オブジェクト指向プログラミング言語のコード生成, などのDDDのタスクで性能が十分か評価する.

適切なテストデータの整備やテストの合否判定が課題になるか. 対象のドメインのコーパスなどの既存資産からいかに効率的に信頼できるテストデータセットを構築するかは重要なテーマになりそうか.
LMを使いながら, 並行する形で訓練データとテストデータ, LMモデルを継続的に育てていくかたちになるのかも..

モデル活用 (Model Utilization for Software Development)

この工程ではLMを活用して対象ドメインのコーパスやドメインモデルを基にソフトウェア開発における成果物の作成やレビュー, 修正(洗練, リファクタリング)を行う. ソフトウェア開発の成果物としては, 要求仕様や設計書, コード, テスト仕様・コードなどが含まれる. ドメインの知識は訓練でLMに学習させる方法や プロンプトでコンテキストとして知識を与える方法, RAGで外部の知識ソースの知識を取得してコンテキストに含める方法などで活用される. LMを工程成果物の作成や評価に活用するだけでなく, 質問応答や分析などのタスクに活用し, 工程成果物を人間が作成するのを支援することを含めてもよい.

適用対象のドメインや組織の開発プロセスにもよるが, LMの活用方法としては以下のようなものが考えられる.

要求仕様の定義

• LMに対象ドメインのコーパスやドメインモデルからソフトウェアの要求仕様の素案を列挙させる.
  • ドメインモデルにドメインのサービスが含まれているとき, それらのサービスの目的は要求に相当するものとして抽出させる.
  • ドメインモデルに不変条件などのルールが含まれているとき, それらは仕様に相当するものとして抽出させる.
• LMにドメインモデルに含まれる共通語彙に基づいて要求仕様のドキュメントを記述させる.
  • 上記で列挙した素案から共通語彙を用いて要求仕様のドキュメントを記述させる.
  • すでに記述されている要求仕様のドキュメントを共通語彙で書き直す.
• LMにドメイン知識に基づいて要求仕様をレビューさせる.
  • ドメインモデルの共通語彙から逸脱した表現がないか確認させる.
  • ドメインのルールにそぐわない記述がないか確認させる.

設計

• LMにドメインモデルを基にI/Fを設計させる.
  • ドメインサービスの情報を基にREST APIのサービス (Swagger json など) を設計させる.
  • ドメインモデルの情報を基に転送するメッセージデータのスキーマやフォーマット (JSON Schema, XSD, OMG IDL, ROS msg など) を設計させる.
• LMにドメインモデルを基にデータ永続化のためのスキーマを設計させる.
  • ドメインモデルの情報を基にER図 (plantuml など) を設計させる.
  • ドメインモデルの情報を基にRDBのテーブルのスキーマ (plantuml など) を設計させる.
  • ドメインモデルの情報を基にGraph DBのスキーマ (SHACL など) を設計させる.
• LMにドメインモデルを基にプログラムのデータモデルを設計させる.
  • ドメインモデルの情報を基に各種プログラミング言語やフレームワークに向けたクラス図 (plantuml など, 修飾子やアノテーションつきのもの) のデータ構造を設計させる.
• LMにドメインモデルを基に既存のスキーマやデータモデルをレビューさせる.

なお, 上記の各種スキーマには不変条件などのルールを含めてもよい. 例えば, 数値の上限下限, 正規表現によるパスワード文字列のフォーマット制約, 確認用パスワード文字列との同一性制約 など.

上記のタスクはLMによらずともルールベースでもある程度は補助できるような印象. LMで上記を実践した例も見られる ⁶.

コーディング

• LMにドメインモデルを基にデータ構造のコードを記述させる.
• LMにドメインモデルを基にデータ(エンティティ)操作のためのコードを記述させる.
  *特にデータ(エンティティ)の基本的な操作のコード記述させる.
  • Factory, Parser(Deserializer)/Dumper(Serializer), Converter, Mapper, Repository などのコードを記述させる.
  • データベース操作のためのクエリ文 (SQL, SPARQL, Cypher など) を記述させる.
• LMにドメインモデルを基にドメインのロジックのコードを記述させる.
  • ドメインの不変条件などのルールを満たしているかチェックするロジックのコードを記述させる.
  • ドメインのサービスの要求や仕様に基づいて処理ロジックのコードを記述させる.

テスト

• LMにドメインの知識やドメインモデルを基にテストケース設計を行わせる.
  • LMにドメインモデルを基に同値クラス分析や境界値分析を行わせる (Feature-oritented Domain Analysis, Object-oriented Domain Analysis などのドメイン分析を含む.)

その他

• LMにDDDに関する知識を問い合わせる.
• LMにドメインの知識(用語やルール, 事例など)を問い合わせる.
• LMにドメインモデルやドメイン知識を基にリスクアセスメントを行わせる.
  • 過去のインシデント事例のコーパスからハザードや脅威を洗い出させる.
  • システムの構成図やドメインモデルを基にリスク分析 (FTA, ATA, STAMP-STPA, ドメイン分析 など)を行わせる.
• LMにドメインモデルについて説明するためのドキュメント生成させる.
  • ドメインモデルのサマリを生成させる (domain vision statement なども含む).
  • 説明用の簡易的なモデルを生成させる.
  • 具体例で説明するためのモデルを生成させる (オブジェクト図, シーケンス図 など)

おわりに

今回のテーマである LM for DDD を 単なるソフトウェア開発にLLMを活用すること(LMASE) や LMをドメインに特化させること, となるべく区別することを意識してまとめてみた.
もっと良いまとめ方があったかもしれないが, 今回はここまで.

次回は "DDD for LM-aided Software Engineering" のテーマで考察しようと思う.

参考文献

1. Comparative Study of Domain Driven Terms Extraction Using Large Language Models ↩ ↩²

2. Domain Knowledge Distillation from Large Language Model: An Empirical Study in the Autonomous Driving Domain ↩ ↩²

3. From Requirements to Architecture: An AI-Based Journey to Semi-Automatically Generate Software Architectures ↩ ↩²

4. Large Language Models and Knowledge Graphs: Opportunities and Challenges ↩

5. GitHub: Awesome-LLM-KG ↩

6. Enhancing Domain-Driven Design with Generative AI ↩