ドメイン駆動設計（DDD）は、ビジネスドメインを、その概念、ユビキタス言語、そしてシステムを組織する責務を特定することで 構造化するアプローチである — 概念、その責務、関係、境界、不変条件、そしてそれらをまとめ上げるアーキテクチャを記述する。 コア、支援、汎用のサブドメインを区別し、その作業は境界づけられたコンテキストを担当するチームが担う。
用法
AI 時代における開発チームの組織化 - Part II.2 は、DDD を「ビジネスは何を表しているのか」という 問いへの答えと位置づけ、「ビジネスはどう振る舞うのか」に答える 振る舞い駆動開発 と対にしている。 この記事の説明では、DDD が構造的なコンテキストを、BDD が振る舞いのコンテキストを提供し、両者が合わさって、AI エージェントが 理解し利用できるビジネスの明示的な表現を生み出す — エージェントは経験豊富な開発者と違って、ビジネスへの直観も暗黙知も 持たないからである。得られたモデル、振る舞い、アーキテクチャ上の決定、品質要件は、その後 仕様駆動開発 を通じて生きた仕様にまとめられる。
同じ記事は、エージェントにどれだけの自律性を与えるかを決めるために DDD のサブドメイン分類を用いている。企業の競争優位が あるコアドメインは、DDD、BDD、SDD への大きな投資と、エージェントが生成したコードの入念なレビューを正当化する。そこでは SDD が戦術的 DDD の Deep Modeling および Supple Design と組み合わさり、ビジネスの反復的な探索を通じてモデルを洗練していく。 支援ドメインは、その複雑さが正当化する場合には恩恵を受けうる一方、ルールの大部分が標準化されている汎用ドメインは、より多くの 自動化や既存のソリューションの採用に向いている。
AI 時代における開発チームの組織化 - Part III は、コードではなくチームを組織するために戦略的 DDD に 目を向ける。記事は戦略的 DDD を、多様な参加者 — ビジネスの専門家、プロダクトマネージャー、UX デザイナー、開発者、 アーキテクト — がドメインについての共通理解を築き、概念、ルール、振る舞いが一貫したまとまりをなす境界を特定する枠組みとして 説明している。ドメインはサブドメインに分かれ、各境界づけられたコンテキストは独自のビジネスモデル、ユビキタス言語、明確に 区切られた責務を持つ。そうしたビジネス上の境界は、その後、チームがライフサイクルを端から端まで掌握できる、一貫性があり 十分に自律的な範囲を軸にチームを組織するために使われる。これはコンウェイの法則に沿ったもので、ビジネス、ソフトウェア、 組織の境界がそろうようにする。記事は、境界づけられたコンテキストはチームの責務を方向づけるが、1 対 1 の対応を課すものでは ないと付け加えている。複雑さと認知負荷が扱える範囲に収まるなら 1 つのチームが複数の境界づけられたコンテキストを受け持つことが でき、一方で最も複雑なドメインや戦略的なドメインは、より狭い範囲に集中するチームを正当化しうる。記事は戦略的 DDD を、チームが 吸収できる認知負荷によってチームの規模を決める Team Topologies と組み合わせ、自ら提案する 拡張 SDLC では DDD を設計（Design）の段階の中心に置いている。そこでは EventStorming ワークショップから得た知識が、集約、ドメインイベント、 ビジネスサービス、ポリシー、ユビキタス言語へと変換される。
適用される場面
- 条件。 パート II.2 の記事は投資をコアドメインに集中させる。パート III の記事は、ビジネス上の範囲を担うチームの レベルで戦略的 DDD を適用する。
- 前提。 ビジネスの専門家とチームがワークショップで協力して共通のモデルを築き、そのモデルがその後もエージェントが 使えるだけ明示的に保たれることを前提としている。
- 失敗モード。 記事は、DDD/BDD/SDD の組み合わせは銀の弾丸ではなく、誤って適用されうると警告している — 過剰な仕様化や 過少な仕様化、知識の重複、進化しなくなった仕様、あるいはニーズではなく解決策を記述した仕様によってである。
- 確立度。 パート III の記事は、DDD を過去 30 年にわたってソフトウェアエンジニアリングを豊かにしてきたアプローチの 1 つに挙げている。DDD をエージェントのコンテキストの構造的な層として、またエージェントとともに働くチームの規模を決める 基盤として位置づけることは、同じシリーズに属する両記事が論じている立場であり、測定された結果ではない。