この記事は、ChatGPTと自分の考えについて会話をした上で、ChatGPTに草稿を書いてもらったものです。(第二弾)

ドメイン駆動設計（DDD）は、単なる技術的な設計手法ではなく、ドメインエキスパートの知識をソフトウェアに正確に反映するための深い探求のプロセスです。このプロセスは、言語学におけるフィールドワークに非常に似ていると私は考えています。言語学者が新しい文化や言語を理解するために現地調査を行うように、DDDも業務の本質を深く掘り下げて理解し、それをモデルとして表現する活動と言えます。

フィールドワークとしての視点

1. 知識の収集と観察

言語学者が現地の言語や文化を観察し、記録するように、DDDにおいてもドメインエキスパートと密接に対話し、その業務や思考プロセスを観察することが重要です。エキスパートが使う言葉や業務の背景にある意図を理解することが、正確なユビキタス言語の構築につながります。

2. 言語と意味の体系化

フィールドワークでは、収集した言語を分析し、文法や語彙を体系化します。同様に、DDDではエキスパートの用語や概念を整理し、それをユビキタス言語として定義します。この言語は、開発チームとエキスパートが共通の理解を持つための基盤となります。

例えば、以下のようなプロセスが考えられます：

• 言葉の整理: エキスパートが使う「顧客ランク」や「発注点」といった用語を収集。
• 意味の確認: それぞれの用語が具体的に何を指し、どのような条件で変化するのかを確認。
• コードへの反映: これらの用語をクラスや列挙型などのプログラミング要素として表現。

3. 誤解の解消

フィールドワークで方言や文脈に起因する誤解を避けるために細心の注意が払われるように、DDDでもエキスパートと開発者の間で認識のズレが生じないよう、継続的な対話が欠かせません。ユビキタス言語は、このような誤解を防ぐための有効な手段です。

4. モデルの進化

言語学者が文化や言語の変化を追い続けるように、DDDでも業務や要件の変化に応じてモデルを進化させる必要があります。ユビキタス言語やドメインモデルは、固定されたものではなく、業務の実態に応じて柔軟に対応できるべきです。

業務理解の深掘り

DDDは、単に業務フローや要件をなぞるだけではなく、エキスパートの思考プロセスそのものを理解し、それをモデルとして表現することに重きを置きます。これを可能にするのが、以下のアプローチです：

• 問いかけ: 「なぜその手順が必要なのか？」、「どの条件で例外が発生するのか？」といった質問を通じて深く掘り下げる。
• 観察: エキスパートが実際に業務を遂行する様子を観察し、その行動と言葉から暗黙知を引き出す。

フィールドワークの成果としてのユビキタス言語

フィールドワークの結果として得られるユビキタス言語は、単なる用語集ではありません。それは、エキスパートと開発者が共通の視点で業務を捉えるための強力なツールです。ユビキタス言語は、以下の特徴を持つべきです：

• 明確性: 業務に関する重要な概念を正確に表現。
• 一貫性: 全員が同じ意味で用語を使用。
• 実用性: ソースコードや設計文書でそのまま活用できる。

ソフトウェア設計と言語学の接点

ソフトウェア設計におけるドメイン駆動設計は、言語学におけるフィールドワークと同じく、深い洞察と綿密な対話を通じて知識を体系化する活動です。エキスパートの頭の中にある業務理解を引き出し、それをモデルとして表現するプロセスは、文化や言語の本質を捉えるフィールドワークと共通しています。

この視点を持つことで、DDDは単なる技術的な手法を超えて、ソフトウェア設計と言語学の共通点を示す一つの学際的アプローチであると言えるでしょう。エキスパートの業務知識を引き出し、共通の言語を通じてシステムとして具現化する。この活動の中に、ソフトウェア設計と言語学が交わる可能性を見出せるのではないでしょうか。