ディベート: 煩わしい詳細

作者 Abel Avram , 翻訳者 笹井 崇司 投稿日 2011年12月4日

セクション

設計/アーキテクチャ

トピック

設計 ,

方法論 ,

プログラミング ,

Architecture ,

フレームワーク ,

Debate

共有 |

原文(投稿日：2011/11/25)へのリンク

BobおじさんとSimon Brown氏がシステムアーキテクチャを描く上でのインフラストラクチャの役割について議論している。

Robert Martin氏（Bobおじさん）は「Screaming Architecture」という投稿でこう主張した。ソフトウェアプロダクトのアーキテクチャは、プロダクトが提供しなくてはならない目的が何であるかを全員に明らかにしなくてはならない、そして、システムのアーキテクチャは利用するフレームワークではなく、そのシステムのユースケースを反映しなくてはならない。

アーキテクチャはフレームワークとは無関係です（もしくは関係すべきではありません）。アーキテクチャはフレームワークによって提供されるべきではありません。フレームワークは利用すべき道具であって、従うべきアーキテクチャではないのです。もしあなたのアーキテクチャがフレームワークに基づいているなら、そのアーキテクチャはあなたのユースケースに基づくことは不可能なのです。

さらにBobおじさんによると、良いアーキテクチャはフレームワークやデータベース、Webサーバーといったものに関する決定を、ほぼ無期限に遅延できなくてはならないという。

良いアーキテクチャというのはプロジェクトのかなり後半まで、Railsを使うのか、Springを使うのか、Hibernate、Tomcat、MySqlを使うのかといった決定を不要にしてくれます。そして、この種の決定を考え直すことも容易にしてくれます。良いアーキテクチャはユースケースを重視し、重要でない事柄からそれらを分離するのです。

Bobおじさんはインターネットをながめて、それは重要でない事柄だと見なせるだろうかと考え、Webもまた「配信メカニズム」であると結論づけた。

Webは配信メカニズムなのです。したがって、あなたのアプリケーションアーキテクチャはそれを単なる配信メカニズムとして扱うべきです。あなたのアプリケーションがWeb経由で配信されるということは詳細であり、システム構成に影響を及ぼすべきではありません。実際のところ、アプリケーションがWeb経由で配信されるということは遅延すべきことなのです。どのように配信されるべきかについて、あなたのシステムアーキテクチャはできる限り無知であるべきです。あなたはそれを、コンソールアプリやWebアプリ、(thick)クライアントアプリ、さらにはWebサービスアプリとして配信できるようにするべきです。それも必要以上に複雑にせず、基本アーキテクチャを変更せずに。

Bobおじさんの結論は「アーキテクチャは、システムで利用するフレームワークではなく、システムそのものについて読者に伝えなくてはならない」ということだ。

ソフトウェアアーキテクトであるSimon Brown氏は、Bobおじさんの言う「配信メカニズム」を「煩わしい詳細」と名付けて、彼の考えにコメントした。彼は、システムアーキテクチャは利用するフレームワークに関係すべきではない、とBobおじさんに同意した。しかしながら、「現実に即したソフトウェアアーキテクチャを見たいのです。それにはテクノロジーの選択も含まれます」と付け加えた。インフラストラクチャの決定を遅らせることについて、Brown氏はこう言っている。「本当に決定すべき重要な技術的選択があるなら、そうすべきではないでしょうか？」そしてこう尋ねる。「もし私が決定を遅らせない、あるいは、遅らせられないなら、そのことはひどいアーキテクチャであることを意味しているのでしょうか？ 延期するというのはルールというよりも意識的な決定なのではないでしょうか？」

Bobおじさんはアーキテクチャの観点からコアドメインだけに注目しているが、Brown氏はこの図にあるように、最近の「配信メカニズム」は非常に巨大なものとなっており、アーキテクチャ全体に組み込まれるべきである、という異なるアプローチをとっている。

Brown氏はこう結論づける。

私にとってアーキテクチャとは、単なる「アプリケーション」内部に含まれるもの以上のものなのです。構造は非常に重要ですが、非機能要件のような厄介なもの、実際の配信メカニズム（テクノロジー、フレームワーク、ツール、APIなど）、インフラストラクチャサービス（ロギング、例外処理、コンフィグレーションなど）、インテグレーションサービス（内部と外部）、環境制約を満たすこと（たとえば運用やサポート）といったものはどうでしょう。私にとって、これはすべて「アーキテクチャ」次第であり、すなわち「ボス」なのです。

議論はここで終わらなかった。BobおじさんはBrown氏の立場に別の投稿「Clean Architecture」で答えた。彼は、UIやデータベースの部分がどれほど巨大であっても、システムのアーキテクチャはそうした「巨大な要素」に重点を置くべきではないという。「ほかの部分はそれから分離すべきなのです」。彼は配信メカニズムからコアドメインを分離するのは非常に重要だと説明した。そして、関連するフレームワークの決定を意図的に延期したり止めたりはしないが、たとえそれらが同時に進行してもアーキテクトは常に2つを明確に分離しておくべきであると述べた。

私がアーキテクチャについてしてきた大げさなコメントのひとつに、良いアーキテクチャはUI、フレームワーク、データベースなどの重大な決定を遅らせることができる、というものがあります。複数の人が、顧客はUIを遅らせたくはないと主張しました。DBA（データベース管理者）はデータベースを遅らせたくはありません。イテレーション毎に、UI、データベース、フレームワークを含めて、システム全体が動くのをみんな見たいのです。ビジネスルールだけに費やされるイテレーションを望んではいません。実際のところ、良いアジャイルプラクティスというのは特に、全体アーキテクチャに長くてスリムなスライスを要求します。

もちろん、私はそれにまったく同意します。しかし、長くてスリムなスライスは連結している必要はありません。良いアーキテクチャはあなたが重大な決定を遅らせることを許容します。あなたに遅らせることを強制するものではありません。しかし、もし遅らせることが可能であれば、あなたは大きな柔軟性を手に入れられます。例えば、最初の数スプリントで暫定的なシンプルなUIを作って、後でもっと機能的なUIに置き換えることもできるのです。

Bobおじさんはこう結ぶ。「最初に煩わしい詳細に取り組んでも、何もわるくはありません。あなたがそれらからビジネスルールを分離している限りはね」

Brown氏は「RE: Clean Architecture」でこれに答えた。彼は分離についてはBobおじさんに同意したが、インフラストラクチャ関連の扱いについては違う立場をとる。「配信メカニズムは遅らせたり無視できる煩わしい詳細ではありません。Bobおじさんの言うように「即破滅」するのです」Brown氏はこう結ぶ。

1. アプリケーションコードをテクノロジーから分離することはよいことであり、私たち全員が努力すべきことである、というのは間違いありません。その結果、コードはユニットテストしやすくなり、置き換えやすくなり、メンテナンスしやすくなり、変更しやすくなります。
2. ソフトウェアアーキテクチャとは全体像であり、アプリケーションコードはその全体像の一部にすぎません。
3. 「配信メカニズム」に関する重要な決定をずっと遅らせて、重要な非機能要件や制約の解決方法を検討しないでいるなら、あなたはソフトウェアプロジェクトを失敗させる危険を冒しています。

BobおじさんとBrown氏は実際のところ正反対の立場をとっているわけではない。どちらもコアドメインとそれを支援するフレームワークとの明確な分離を支持しているが、前者はドメインにフォーカスし、後者はそのインフラストラクチャも検討、考慮されるべきだと考えている。あなたのアプローチはどうだろうか？