ITアーキテクチャ構築の勘所
第3回 機能的なアーキテクチャの設計

日本IBM
ICP-エクゼクティブＩ/Ｔアーキテクト
河野紀昭
2006/1/6

　アーキテクチャ要件の洗い出しに続くITアーキテクチャ設計のステップは、機能的なアーキテクチャ設計である。ここでは、システムを構成する機能をコンポーネントとして切り出して構造化するが、役割分担を明確にしたシンプルな構造を作ることが、良いアーキテクチャへの近道である。

　今回から、ITアーキテクチャを具体化していくステップに入る。ところで、ITアーキテクチャというのは、そもそもどのようにとらえたらよいのだろうか。

　私は、ITアーキテクチャを「ビジネスの要求にIT技術を用いて応えるための青写真であり、システムを構成する要素とその構造を、静的および動的に表したもの」と考えている。例えば、魅力的なWebサイトをオープンし、お客さまにたくさん買い物をしてもらいたい、といったビジネス要求に対して、こんなIT技術を使って、こんな仕組みとシステム構成で実現するとうまくいくという姿を表したものがITアーキテクチャだ。

　ITアーキテクチャ設計上、まず考慮すべき点として、「関心事の分離」がある。もし、会員登録や注文処理といった業務機能と、セキュリティ／耐障害性などから必要な機能をいっぺんに盛り込んだアプリケーションを作ってしまうと、どうなるだろうか（図1）。

図1 機能の重複が多い複雑な仕組み

　ここでは、おのおのの業務処理にトランザクション制御機能やセキュリティ機能が組み込まれ、さらにバックアップのための仕組みが業務的に用意されている。これでは、機能の重複が多い複雑な仕組みになってしまい、セキュリティ要件が変わったというような事態が生じると、メンテナンス不能に陥ってしまうだろう。

　上記は極端な例だが、本来、トランザクション制御機能やセキュリティ機能は、できるだけ業務と独立した機能として設計するとよい。バックアップは後で考慮することにして、設計の考慮点から外し、機能を整理した設計にすると図2のようになる。

図2 機能を整理した設計

　図2の構造であれば、システム的な機能が機能ごとに分離されており、システム的な要件が変わっても業務プログラムが影響を受けることは少なくなる。

勘所：関心事を分離せよ

　 アーキテクチャ設計の進め方としても、「関心事の分離」は良いアプローチで、まず、業務に密接な機能を、機能的なアーキテクチャとして整理し、バックアップなどハードウェアと密接に関係する要件は、後続の配置設計などで吟味するとよい。

　機能的なアーキテクチャ設計のステップでは、業務の処理を行うために必要なシステムの機能をコンポーネントとして適切に洗い出して構造化する。具体的には、次の3つの設計作業を行えばよい。

（1）主要コンポーネントの洗い出し

　業務処理を行うために、必要となる主要機能を洗い出し、システムを構成するコンポーネントの候補とする。前回の連載で述べた主要ユースケースに対して、シーケンス図を描きながら必要コンポーネントを洗い出す方法も有効である。

　なお、ここでのコンポーネントは、アーキテクチャ上必要な機能を抽象化したものであり、プログラミング上のクラスやモジュールより大きな粒度となる。また、業務の機能をすべて網羅する必要はなく、必要なシステム機能が洗い出されていれば良い。

（2）コンポーネントの構造化／レイヤ化

　洗い出されたコンポーネントの責務を検討し、複数の責務を1つのコンポーネントが持っている場合には、コンポーネントの分割を検討する。逆に、広い意味で同じ責務を担当するコンポーネントが複数ある場合には、1つのコンポーネントに統合することを検討する。分割／統合時には、コンポーネント同士ができるだけ疎結合になるように配慮する。

　コンポーネント間の呼び出しがある場合、呼び出すコンポーネントと呼び出されるコンポーネントを整理し、レイヤ化すると良い構造になる場合が多い。レイヤ化する場合には、上位のレイヤのコンポーネントが下位のレイヤのコンポーネントを呼び出すように、モデリングする。また、Model View Controller（MVC）などのアーキテクチャ・パターンを導入することも有効である。

（3）業務とシステムを分離して構造化

　「関心事の分離」の原則に従って、業務とシステム的な機能を分離して構造化する。システム的な機能はミドルウェアやフレームワークによって実現されることが多いので、業務と明確に分離しておくとよい。

　ここで、図2に戻り、この例の構造化を進めてみよう。図2は、（1）の作業を行った状態であり、レイヤ化は行われていない。業務機能のみを取り出して、（2）の作業を行い、レイヤ化を行うと図3のようになる。

図3 レイヤ化により、業務コンポーネント間の依存関係が分かりやすくなる

　レイヤ化により、業務コンポーネント間の依存関係が分かりやすくなる。また、レイヤにコンポーネント配置を行う過程で、コンポーネントの過不足を吟味できる。この例では、業務データモデルのレイヤに必要なコンポーネントを追加している。

勘所：レイヤ化してコンポーネントの依存関係と責務を整理せよ

　さて、図2に対してシステム機能を追加して全体を整理しよう。システム機能は、業務の下位レイヤとして整理することが多いのだが、フレームワークを採用している場合には、フレームワークが業務を呼び出す構造になる場合が多く、すべてを縦にレイヤ化するとレイヤが深過ぎて分かりにくくなる。

　そこで、画面／業務／データモデルという業務的なレイヤ構造を横に、フレームワークを含めた制御上のレイヤ構造を縦に表して、機能的なアーキテクチャを整理するとよい（図4）。

図4 機能的なアーキテクチャを整理する

　このように業務とシステムを分離して構造化を行えば、業務担当者は業務ロジックの開発に専念することができる。また、構造化されているので、変更に強く再利用性の高いシステムとすることができる。

勘所：業務とシステムを分離して構造化せよ

【プロフィール】

河野紀昭（こうの のりあき） 日本IBMにてITアーキテクトとしてさまざまなプロジェクトでアーキテクチャ設計を10年以上にわたって実施してきた。現在、エクゼクティブITアーキテクトとして、システムのアークテクチャ設計を担当するとともに、後進の指導にも当たっている。

IT Architect 連載記事一覧