『手を動かしてわかるクリーンアーキテクチャ 』の第二章の冒頭に登場する話題に共感したので紹介。
従来の多層アーキテクチャでは、データベースを中心にアプリケーションの 開発が行なわれます。この場合、Web 層はドメイン層に依存し、ドメイン層は 永続化層、つまり、データベースに依存することになります。そうなると、す べてのものは永続化層上に構築されることになり、その結果、いくつかの要因 が絡まり合って、問題が起きやすくなります。
手を動かしてわかるクリーンアーキテクチャ ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発 20p
著者によれば、機能開発をデータベース中心に設計すると、ドメイン層と永続化層の密結合が発生し、保守性が低下することがある。この問題を解決するために、本の後半でヘキサゴナルアーキテクチャ1による解決策が提示されるという構成になっています。
例えば、機能開発を以下のようなフローで進めると、このアンチパターンに陥りやすくなります。
- カンプデザインから開発を開始する。
- これを実装するためにデータベース設計を考える。
- データベースに保存するコードを作成する。
- ビジネスロジックを完全に実装する。
- Viewにデザインを適用し、全体を繋げて完成させる。
ORMのAPIを使えばオブジェクトをモデルとして表現できるため、ビジネスロジックに自然に組み込むことが可能です。そのため必然とビジネスロジック内にDBの呼び出しが発生します。なので、一部の人々はこれをORMのせいにすることもあります。
ヘキサゴナルアーキテクチャでは、ビジネスロジックはインターフェイス（ポート）のみに依存し、データベースとの結合をアダプタ層へ切り離します。そのため、内部でデータベースの読み込み方法を変更したり、キャッシュ操作などをしてもビジネスロジックには影響がないとされています（本当か？）。
私のやり方
「初手で2回実装する」
まず、プロトタイプはUXテストだけを目的に実装します。多くの場合、MVCフレームワークのコントローラーレイヤー（本書で言うWeb 層）にベタ書きします。
人間の使い心地を確認したのち、次の段階でソフトウェア視点での使い心地を考慮して書き直します。この時、インターフェイスを決定し、全てのマイグレーションを無かったことにして、インターフェイスからクエリを決め、スキーマも決定します。実行計画でクエリの効率もこの時点で確認しておく。
インターフェイスが決まったら、それを使ってテストコードとプロダクションコードを書きます。Viewレイヤーは、プロトタイプのものをそのまま使えることが多いです。
一発で解決するのは難しいため、このスタイルに落ち着きました。2倍の時間がかかるかというとそうでもありません。ほとんどがコードの移動作業ですし、UXテスト中に発生する「やっぱりこう変えたい」という手戻りを回避できるので、感覚的には同じくらいの時間で済むと感じています。
- 本書ではクリーンアーキテクチャを実現するための具体的なアーキテクチャの1つがヘキサゴナルアーキテクチャであると解釈します↩
