ドメイン駆動開発_フォルダー構成編_#03_依存関係

ここまでで，プロジェクトを４つ作りましたが，今回はそれらのプロジェクトの依存関係をどのように設定するかというお話をしていきたいと思います。

依存関係とは？

依存関係とは，どのプロジェクトが，どのプロジェクトを参照するか？ということで，参照するというのは，他のプロジェクトの機能を使えるようにするか？という事です。

例えば，Domainの機能をInfrastructureで使いたければ，InfrastructureでDomainのプロジェクトを参照しておく必要があります。どれであればすべてのプロジェクトを参照すればいいのでは？と思うかもしれませんが，そういうわけにもいきません。参照関係とは，１方向にしか行えないので，InfrastructureがDomainを参照した場合，DomainからInfrastructureは参照できなくなります。なので，参照関係をどのように設定するか？というのは，最初に決める，非常に重要な設定となります。ちなみに，双方向で参照しようとすると，C#は循環参照というエラーでそのような設定ができないことを通知します。

双方向の参照関係が設定できないのであれば，わざわざプロジェクトを分けずに，１つのプロジェクトにしてしまえば，すべての機能をすべてのクラスで使えていいのではないか？と思うかもしれません。しかしそれも賢明な選択とは言えません。

プロジェクトを分けるにはそれ相応の意味があります。プロジェクトを１つにしてすべてのプログラムコードを書いてしまうと，すべてのコードが至る所で使用されている可能性があるため，可読性が落ちます。プロジェクトを分けていれば，例えばInfrastructureがDomainを参照し，Domainがどこも参照していない場合は，DomainではInfrastructureやWinFormの機能を使用していないことが明確になります。WinFormにWindowsフォームにまつわる機能しか実装していない場合，いつの日かWPFに変更する際も，WinFormのプロジェクトだけを取り換えれば動作するようになります。すべての機能を１つのプロジェクトに入れていては，どこまでがWindowsフォームに依存するコードかが，判断できないため，WPFの移行が非常に大変な作業になります。

WindowsフォームからWPFへの移行など，時代の変化とともに進化していくテクノロジーと，純粋なC#のビジネスロジックを分離してコーディングすることで，時代の変化に振り回されずにシステム開発をしていくことが，プロジェクトを分離する狙いです。

参照関係

それでは具体的な参照関係を説明します。

まず，「Domain」プロジェクトはどこも参照しません。このプロジェクトは最上位に位置し，どこのプロジェクトにも依存しない，純粋なC#のビジネスロジックの集まりとなります。

続いて，「Infrastructure」プロジェクトは「Domain」プロジェクトを参照します。

「WinForm」プロジェクトは「Domain」プロジェクトと「Infrastructure」プロジェクトを参照します。

単体テストプロジェクトは「Domain」プロジェクト，「Infrastructure」プロジェクト，「WinForm」プロジェクトのすべてのプロジェクトを参照します。

各種プロジェクトの意味

依存関係は前述した通りですが，ここで，各プロジェクトがどのような意味を持つのかを，整理しておきます。

Domainプロジェクト

Domainプロジェクトはどこのプロジェクトも参照せず，純粋にプレーンなC#のコードのみをコーディングします。この部分にビジネスロジックを記述します。ビジネスロジックとは，アプリケーションで独自に決める仕様です。そのアプリケーションで表現したいことです。そのアプリケーションで行う計算や，判定ロジックをここに集めます。ビジネスロジックとは，アプリケーション独自のロジックなので，何らかの事情で仕様が変更されたときにロジックを変更する必要があります。その際に，どこに書いているのか？というのが，即時にわかるべきだし，また，同じロジックがいろんな場所に散らばっていてはいけないのです。

例えば消費税の計算なんかは1か所でやるべきだし，各画面に散らばっていて，いろんなところを変更して，「一部5%のままで残っていました」なんてことがあってはならないのです。どこかの1か所を変えれば，すべてが変更されるようになっているべきだし，自信をもって変更できるような，わかりやすい場所に記述されているべきです。

こういった感じで，ビジネスロジックとは，アプリケーションで表現するべきロジックを集中して記述していきます。どのようにクラスを分割するのかは，後述するので，楽しみにしておいてください。

Infrastructureプロジェクト

Infrastructureプロジェクトは，外部との接触部分を記述します。例えばSqlServerとかオラクルデータベース，ファイルへのアクセス，PCとの通信等です。自分が作成しているアプリケーションの外側へアクセスする部分のみを記述します。

なぜ外部との接触部分をInfrastructureプロジェクトに記述するかというと，外部の変化に振り回されずにコーディングをするためです。

外部のシステムは，外部の事情で変化します。例えば，SqlServerはSqlServerの勝手なタイミングでバージョンアップします。その際に，今まで使えていた関数が無くなったり，メモリリークの問題が発見されて，何か処置するコーディングを入れないといけなくなったりするかもしれません。そういったマイクロソフトの事情以外にも，我々の仕様の事情で，列を追加したり，文字数を減らしたり，増やしたり，カラム名を変更するかもしれません。そういったときに，プログラムの至る所で，SqlServerに接触していると，修正すべき箇所というのが，非常に分かりづらくなります。

すべての箇所を修正できたのかも，判断できないようになるのです。例えば，購買システムのアプリケーションを作成して，100画面くらいがSqlServerにそれぞれアクセスしていると，本当に必要な個所をすべて修正できたかを確認するのは，非常に大変です。

ですから，そういった外部の事情で変更されるようなものは，1か所にまとめてアクセスし，1か所でケアできるような構造にするのが望ましいという事になります。

だからInfrastructureプロジェクトではSqlServerにアクセスする部分やファイルにアクセスする部分などを，局所的に実装することで，外部の変化に振り回されずにコーディングをしていきます。また，このような実装をすることで，プログラムとしても見通しが良くなります。

あとは，それ以外にも，外部との接触部分というのは，テストコードからテストしづらいという特性があります。コードでテストする場合に，外部のシステムとの連携部分は，ダミーのデータを流し込む等の工夫が必要です。そういった意味でも，外部接触部分はプロジェクト単位で切り離しておいたほうが，実装がしやすくなります。このあたりのテストコードの書き方も後述しますので，楽しみにしておいてください。

WinFormプロジェクト

このプロジェクトも，前述した通り，時代の変化によって変化が必要な部分です。例えばWindowsフォームからWPFに変更したくなった場合に，変更が必要な部分だけをWinFormに集めておけば，その部分のみWPFに置き換えれば，InfrastructureとDomainは一切の変更が不要で，そのまま使用することができます。なので，このプロジェクトはWinFormをWPFに変更する際に，書き換えないといけない機能のみを実装する，という感覚で感じてもらえればいいかと思います。