EIPの4つの連携方式。ファイル、RPC、データベース、非同期メッセージング。REST APIはRPC。
それぞれ得意分野や特性が異なる。どちらでも実装できる領域は多い。
そういう場合、よりその方式らしさを活かせる方を選択する。機能の追加や横展開をした時の特性を見据えて。
ドメイン駆動設計の文脈で４つの方式を考えてみる。人間の仕事のやり方は非同期メッセージングが基本。ただ実装技術としての非同期メッセージングは、人間ほど、例外や異常にうまく対処できていない。直接的な写像は、まだ無理がある。
そういうミスマッチがあるとしても、ドメインの活動のモデリングの手がかりとして、EIPが提示するパターンはとても興味深い。 実装パターンだけでなく、分析パターンとしても使える。
EIPの他の３つの方式も、分析パターンとして見てみると面白い。データベースを使った連携は、人間の仕事のやり方に合致しているのか？ ファイル転送は？ REST API は？ 非同期メッセージングに比べると、人間のやり方とは違う方向に進んでいる感がある。
REST API は切り刻みすぎ。文脈や時系列のプロトコルの設計が甘くなりやすい技術。共有データベースは、一元化をやり過ぎる。異なる文脈の微妙な関心ごとを軽視した設計になりがちな技術。当初の意図に反して、ソフトウェアの変更のマイナス要因になっているケースが多い。
どんな技術方式でも理想的な設計ができれば素晴らしい効果を発揮する。
現実は、そこそこの設計ができれば良い方。間違いが多く、変更の繰り返しで設計が劣化していく。
技術方式は、理想的な設計を前提にしちゃいけない。間違いに後から気付き、追加や拡張を繰り返すことを前提に議論する。
ドメイン層をオブジェクト指向で実装する良い点。分析しながら、そのままコードを書き始めれば良いので無駄な作業が減る。勘違いや見落としに気がついたり、新たな気づきがあった時、コードの変更が楽で安全。
要するに適切なソフトウェアをスピード感を持って育ていける。それがドメイン駆動設計。
ドメイン駆動設計をやるよになってから、本を読めば読むほどオブジェクト指向が基本であることに気づき、設計技法としてメイヤーの契約による設計の大切さを知り、契約による設計の基本は、抽象データ型によるモジュール化であることにたどり着いた。今はここ。さて次は...。
※EIP＝Enterprise Information Portal