BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース アーキテクチャの目的は意図であり、フレームワークではない

アーキテクチャの目的は意図であり、フレームワークではない

原文(投稿日:2013/07/03)へのリンク

アーキテクチャの目的は意図であるが、私たちはそれをフレームワークや詳細だとしてきた。「ボブおじさん」ことRobert C. Martin氏はロンドンで開かれた今年のDDD Exchange Dayこのように述べた

Robert氏は「Growing Object-Oriented Software Guided by Tests」という本で説明されたアーキテクチャモデル(Hexagonalアーキテクチャに似ている)について言及した。その本では、不安定な部分から安定した部分へと、一方向の依存関係を持つ3つのゾーンを持ったアーキテクチャについて説明している。

  • ドメインモデル。コアとなるビジネスルール、ビジネスにとって最も安定して重要な部分を持ち、他には依存しない。
  • アプリケーションサービス。ドメインモデルを利用し、ドメインモデルに依存したシステムのユースケースを実現する。
  • 外部詳細。データベース、ユーザインターフェイス、ネットワークなど、ビジネスモデルにはそれほど関係がない。最も不安定で他の2つに依存する部分。

彼が重要だと考えていること、アーキテクチャの目的は意図、すなわちアプリケーションがやることだということは、このモデルだとうまく説明できないと彼は述べた。私たちは詳細やフレームワークにフォーカスしすぎており、それらをシステムの中心にしてしまっていると彼は考えている。
この欠点を解決するため、Robert氏はIvar Jacobsonによる1992年の本、「Object-Oriented Software Engineering, A Use Case Driven Approach」に立ち戻った。その本でIvar氏は、詳細ではなく小さなユースケースに基づいたアプリケーションアーキテクチャの仕組みを定義している。
Ivar氏はアーキテクチャモデルに合った3種類のオブジェクトを紹介しており、Robert氏はこれらを次のように説明した。

  • インタラクタ。ユースケースを理解し、アプリケーション固有のビジネスルールを持つ。
  • エンティティ。ビジネスルールを持ち、インタラクタによって利用される。
  • バウンダリオブジェクト。外部世界とインタラクタとの間でデータを転送する。

Robert氏が言うには、このモデルの大きなメリットは、テスト可能なモデルだということだ。バウンダリオブジェクトを通してデータ構造を送受信することによって、インフラストラクチャに依存することなくテストが可能になる。

そして、Robert氏はさきほど説明したアーキテクチャの一種である、Cleanアーキテクチャモデルに話を移した。3つのモデルすべてで重要なのは、これらのモデルが安定依存の原則(Stable Dependencies Principle)に従っているということだ。「変更するもの、あるいは変更する可能性の高いものに依存してはいけない」。外部にある不安定な部分をより安定した部分、例えばドメインモデルに依存させることで(逆向きではない)、これを実現している。またこれにより、実装は変更しやすくなる。不安定な部分が安定した部分に依存しているためだ。Robert氏の言葉を引用すると、

すぐれたアーキテクチャとは、簡単に変更できる不安定な決定を許すものです。

Robert氏はまたJim Coplien氏とDCIアーキテクチャに言及した。彼はこれをほかのアーキテクチャとよく似ていると考えている。

この数年、Robert氏のこうした考え方に対して、いくつか批判もあがっており、Robert氏もこうした批判に対して回答している

この記事に星をつける

おすすめ度
スタイル

BT