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

なぜか会話してない部分についてまで、自分の意見に近いことを書いてくれており、驚いています。俺が過去に書いたブログ記事を読んだんだろうか？

エリック・エヴァンスの『ドメイン駆動設計』は、私にとって非常に印象深い一冊です。しかし、この本は時として誤解されがちです。特に、その内容をパターン集として捉え、設計パターンを表面的に取り入れるだけで終わってしまう事例を多く見かけます。これにより、ドメイン駆動設計（DDD）の本質が見失われることが多いと感じています。

ユビキタス言語を中心に

私が理解するDDDの本質は、「ユビキタス言語（Ubiquitous Language）」を中心に据えることにあります。ユビキタス言語は、開発者とドメインエキスパートが共有する言葉の枠組みであり、この言語を通じてドメインモデルが構築されます。この言語の核となるのは、ドメインエキスパートが使用する語彙です。

語彙とビジネス概念

この語彙は単なる「言葉」ではなく、「ビジネス概念」であると私は考えています。たとえば、販売業務では「顧客ランク」や「売上ステータス」が重要な概念であり、在庫管理では「発注点」や「有効期限管理」といった概念が挙げられます。これらのビジネス概念を正確に理解し、それをユビキタス言語に取り込むことが、DDDの出発点です。

ビジネス概念の表現

ビジネス概念は、ソースコードの中で自然に表現されるべきです。これは、次のような基本的なプログラミング要素で実現されます：

• クラス: 例えば、「顧客ランク」を表す CustomerRank クラス。
• 列挙型: 「売上ステータス」を表す SalesStatus 列挙型。

これらのプログラミング要素は、ユビキタス言語と一致する名前を持ち、ドメインエキスパートの認識と一致した形で表現されるべきです。

知識の分離

システム内のビジネスロジックを整理する際に重要なのは、異なる業務領域の知識を分離することです。販売と在庫管理のように、異なるドメインエキスパートが持つ知識をコード内で混在させるべきではありません。このような分離は、SOLIDの単一責任の原則（SRP）やDDDの境界づけられたコンテキスト（Bounded Context）の考え方と一致します。

ドメインモデルの価値

DDDの目的は、単に設計を美しくすることではなく、ドメインエキスパートと開発者が同じ言語で話し合える基盤を築くことにあります。その結果として生まれるドメインモデルは、業務の本質を捉え、変更に強いシステムを構築するための指針となります。

終わりに

『ドメイン駆動設計』は、単なるパターン集ではなく、開発チームとドメインエキスパートが連携してビジネスの本質を捉えるためのアプローチです。ユビキタス言語とビジネス概念を中心に据えた設計が、DDDの真価を発揮する鍵だと私は考えます。