ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法

8章

技術方式

　ここまで、業務ロジックのモデリングと実装のやり方を検討してきました。この章では、もっと広い範囲の実装方法を探求します。つまり、アプリケーション全体を組み立てるために、コンポーネントどうしの相互作用と依存関係をどのように構造化するか、その方法です。

8.1　業務ロジックと技術方式

　業務ロジックは何よりも重要です。しかし、ソフトウェアの唯一のコンポーネントではありません。機能要件や非機能要件を満たすために、コードベース全体ではもっと多くの責務が求められます。入力情報を収集し出力を提供するために、ユーザーと対話する必要があります。状態を永続化するためにさまざまな永続化の仕組みを利用します。外部システムや情報提供サービスとの連係も必要です。

　このように、コードベースが扱うべき関心事は多岐にわたります。そのため、業務ロジックはあちこちに拡散しがちです。つまり、業務ロジックの一部がユーザーインターフェースやデータベースに実装されたり、異なるコンポーネントに重複して実装されたりします。実装の関心事を適切に構造化できていないコードベースは、変更がやっかいで危険になります。業務ロジックを変更しなければならない時に、どの部分が変更の影響を受けるのかがわかりにくくなります。一見無関係に見える部分に、予期せぬ影響が及ぶ可能性があります。逆に、変更しなければならないコードを見逃してしまうこともあります。これらの問題はすべて、コードベースの保守費用を劇的に増大させます。

　アプリケーションを構築するための技術方式（アプリケーションアーキテクチャ）は、コードベースのさまざまな関心事をどう構造化するかの原則を導入し、それぞれの関心事の境界を明確にします。つまり、業務ロジックを、システムの入力、出力、その他の基盤コンポーネント群とどう結びつけるかを定義します。どの技術方式を選択するかによって、コンポーネントの相互作用、つまり、コンポーネントどうしがどんな知識を共有し、どのようにお互いを参照するかが変わります。 ...