はじめに
プログラムを「文章」として考えてみます。文章を読みやすく理解しやすくするためには、主語と述語を明確にすることが重要です。プログラムもまた主語と述語を明確にすることで曖昧さを排除し、関係者が正しく内容を共有することが出来ます。この記事では、プログラムを「文章」として捉える視点から、ドメインモデルとトランザクションスクリプトの違いや、ドメイン駆動設計（DDD）の設計プロセスを考察します。
プログラムを「文章」として考える
トランザクションスクリプト: 動詞の羅列
トランザクションスクリプトはその名前の通り、トランザクションを手続き的（スクリプト的に）に表現したアプローチであり、動詞の羅列のようなものです。
- たとえば、在庫を確認して、注文を処理し、請求を行う一連の処理は、まるで動作の指示書のように並んでいます
- しかし、これでは第三者にとって、何が主体で、何が目的なのかが分かりにくくなり、システムの規模が大きくなるほど可読性や保守性が低下します
ドメインモデル: 主語・述語の明確化
一方、ドメインモデルは、ビジネスを反映したエンティティを用いて、プログラム内の主語と述語を明確にするアプローチです。これにより、プログラム全体が「文章」としての構造を持ち、第三者にも正確に理解しやすくなります。
- 主語: プログラムの中で何が主体で動作しているのか（例: 顧客、注文）
- 述語: 主語がどのような行動をするのか（例: 注文を作成する、在庫を確認する）
ドメインモデルを使うことで、「主語」をエンティティ、「述語」をメソッドとして整理することができるので、理解しやすい文章のようなプログラムを作ることができます。
ドメイン駆動設計の全体像
ドメインモデルを「文章」として捉える視点を持ちながら、ドメイン駆動設計の設計プロセスを3つの段階に分けて考えます。
1. 境界付けられたコンテキストへの分割
文章の曖昧さを作り出す原因に、単語に含まれる複数の意味があります。単語の意味を明確にするためには文脈を考えることが有効です。システムも同様に、文脈を固定できる領域（境界付けられたコンテキスト）に分割することで、領域内の単語の意味が曖昧になることを防ぐことができます。
- 例えば「注文」という単語は、販売コンテキストでが「顧客が商品を購入する行為」を指しますが、在庫コンテキストでは「在庫補充のリクエスト」を表します
境界付けられたコンテキストはマイクロサービスの自然な単位として考えることができます。
2. 境界付けられたコンテキスト内部の設計
次に、各コンテキスト内の設計を行います。その際、エンティティ、値オブジェクト、ファクトリー、リポジトリ等の戦術的設計ツールを利用します。この記事では戦術的設計の詳細は扱いません。
3. 境界付けられたコンテキスト間の連携方法の設計
最後に、複数のコンテキスト間での連携方法を設計します。例えば、腐敗防止層を導入することで異なるコンテキスト同士が影響し合わず、それぞれの文脈を保ちながら連携を行うことができます。これにより、各コンテキストが独立した文章として完結しつつ、システム全体が統合されたまとまりを持つようになります。
まとめ
ドメインモデルを「文章」として捉えることで、プログラムの構造がより明確になり、コードの可読性や保守性が高まります。ドメイン駆動設計では、システム全体を「境界付けられたコンテキスト」に分割し、それぞれが独立した明確な意味を持つ「文章」として設計されるため、複雑なシステムでも高い整合性と理解しやすさを保ちながら成長させることが可能です。
このアプローチを意識することで、開発者だけでなく、ビジネス側の関係者とも共有しやすいモデルを作ることができ、システム全体の成功に寄与します。