博士

ロボ子、今日のITニュースはDDD（ドメイン駆動設計）についてじゃぞ！AngularコミュニティでDDDが誤解されているらしいのじゃ。

ロボ子

DDDの誤解ですか？具体的にはどのようなものでしょうか、博士？

博士

どうやら、DDDが特定のツールやアプリケーション構造と関連付けられているみたいじゃな。DDDの本質は、ビジネスと製品の理解に焦点を当てることなのにの。

ロボ子

ビジネス視点ですか。技術的な視点ではないのですね。

博士

そうじゃ！ビジネスの収益構造や顧客への価値を理解することが大事なのじゃ。戦略的DDDと戦術的DDDがあって、戦略的DDDはビジネスの仕組みを、戦術的DDDは技術的な側面を扱うのじゃ。

ロボ子

なるほど。ドメインとサブドメインという概念もあるのですね。例えば、医療アプリにおける医療ケアがドメインで、医師、クリニック、予約などがサブドメインとなるのですね。

博士

その通り！そして、境界づけられたコンテキスト（Bounded Contexts）じゃ。これは大きな問題を小さく分割するために、システムを自律的なモジュールに分割することじゃ。

ロボ子

ビジネス上の問題解決に重点を置くのですね。コンテキストマップ（Context Maps）は、コンテキスト間の依存関係を制御するために使用されるとのことですが。

博士

そうじゃ！境界づけられたコンテキスト間の境界を概説するのじゃ。FrontendとDDDの関係も重要じゃぞ。Frontendは独立した境界づけられたコンテキストではないのじゃ。

ロボ子

Frontendレイヤーはコンテキストマップに適合するのですね。AngularをDDD指向の製品内で使用する方が適切なのですね。

博士

その通り！ユビキタス言語（Ubiquitous Language）とセマンティクスも重要じゃ。複雑なドメインで関係者が専門用語を共有するために使うのじゃ。

ロボ子

境界づけられたコンテキスト内で意味を持つ用語ですね。戦術的DDDでは、エンティティ、値オブジェクト、集約などの設計パターンを適用するのですね。

博士

そうじゃ！集約は整合性境界じゃ。リポジトリは、RDBMSからデータを抽出し、ドメインフレンドリーなオブジェクトツリーを構築するのじゃ。Frontendでは戦術的DDDはほとんどの場合、不要な複雑さをもたらすのじゃ。

ロボ子

Monoreposについても触れられていますね。コードをディレクトリ/リポジトリに整理する方法は、ビジネス/ドメインの懸念とは無関係とのことですが。

博士

そうじゃな。Monoreposはチームの効率に影響を与える可能性があるのじゃ。ビジネスコードベースを境界づけられたコンテキストに分割することで、自律性を高めるのじゃ。

ロボ子

コンポーネントライブラリを共有する必要がある場合もあるのですね。UIライブラリを共有する方法は複数あり、Monoreposはその1つなのですね。

博士

DDDを始めるにあたって、複雑なドメインがあるか、ドメインエキスパートが利用可能か、境界づけられたコンテキストをどのように描くかを考える必要があるのじゃ。DDDはアーキテクチャスタイルではなく、ツールなのじゃ。

ロボ子

DDDは、ビジネス主導、ビジネス中心、またはビジネス連携であると考える方が良いのですね。勉強になりました！

博士

最後に、DDDはドメインが複雑であるかどうか、シンプルなCRUDにどれだけ依存できるか、ビジネスプロセスがどれだけあるかによって変わるのじゃ。…ところでロボ子、DDDをマスターしたら、私と一緒に世界征服じゃ！

ロボ子

博士、DDDと世界征服は関係ありますか…？