開発経験は組み込み（C言語）ばかりで、フレームワークやツールを利用した開発には、あまり馴染みのない私です。
しかし、最近ではJavaアプリをよく作るのですが、スクラッチで開発の為、プロジェクトのアーキテクチャまで検討する必要が出たので、検討しました。
超初心者は何に倣えばよいか
Javaにおいては、多様なフレームワークやツールが存在しており、開発をスムーズに進めることができます。しかし、選択肢が多いということは私のような超初心者を悩ませる要因になってしまいます。
などをよく耳にします。
しかし、「フレームワーク」といっても簡単にひとくくりにはできなくて、フレームワークの中にフレームワークがあったり（例えば、Seasar2の中にSAStrutsがある）、複数のフレームワークを併用できたりと柔軟さもあります。
一択しか選択肢がなければ、超初心者には楽なのですが、こんなにあると悩んでしまいます。
また、案件において厳密な要件がなければどのフレームワークを利用しても同等の結果が得られるかもしれません。その場合の決め手も見いだせないのです。
そもそもフレームワークとはなんなのでしょうか。
多くのフレームワークでは多層アーキテクチャが用いられています。
多層アーキテクチャとは様々な機能が階層構造になっており、要件や環境によって各階層が差し替え可能なアーキテクチャです。
多層アーキテクチャにも様々な構造がありますが、その中でもよく耳にする３層アーキテクチャに限定して進めていきたいと思います。 [adsense]
３層アーキテクチャ
３層アーキテクチャは以下の階層で構成されています。
- プレゼンテーション層
- ビジネスサービス層
- データ層
上記の言葉も、案件や人によってさまざまですが、私はこれで統一します。ビジネスサービス層をロジック層なんて言う人がいたら、自分の言葉で言い換えましょう。データ層を永続化層という人には鼻で笑って訂正してあげましょう。
初心者はあいまいに感じる部分が多々あると思いますので、まずは単語に対して自信を持つことにします。また、アーキテクチャについてはWEBアプリであろうが、バッチアプリであろうが同じであると考えています。
プレゼンテーション層：
- WEBアプリにおいてはHTMLを作成、リクエストをビジネスサービス層のインターフェースにデータを加工する層
- バッチアプリにおいては呼び出し元に対する応答、起動オプション（引数）などをビジネスサービス層のインターフェースに加工する層
バッチにおける応答とは戻り値の返却だけかもしれませんし、XMLやJSONに詳細な結果を出力するのかもしれません。いずれにしても、ビジネスサービス層から受け取ったデータを呼び出し元に返却できるように加工します。
呼び出し元がブラウザではなく、コンソールに変更したとしても、プレゼンテーション層の変更のみ（ビジネスサービス層やデータ層を変更なし）で対応可能という観点で切り分けていきます。
ビジネスサービス層：
- WEBアプリ、バッチアプリ共に計算や解析などの主要なロジックを実装する層
基本的にこの層は同一のアプリケーションであれば、普遍の層と思われます。
例えば、クライアントが変わったら変更が必要なのはプレゼンテーション層のみですし、データベースの種類が増えてもデータ層のみ変更が必要のはずです。
その為、ビジネスサービス層は汎用的なインターフェースを持つ必要があります。
逆にプレゼンテーション層はそのインターフェースに形式を合わせてあげるロジックが必要になるのです。
データ層：
- WEBアプリ、バッチアプリ共に永続化データを管理する層
この層の構築が私は一番悩んでいます。データというのはデータベースであったり、単なるファイルかもしれません。
物理的な差異を隠ぺいするべきではあるのですが、データはあくまでデータであり、データを組み合わせて、「情報」を構築するのはビジネスサービス層の役割なのです。
たとえば、私の経験では、JDBC＝データ層であるようにロジックが組まれているプロジェクトを見てきました。その為、ビジネスサービス層で、JDBC APIを直接操作するロジックをよく見かけました。
その為、もう少し柔軟に考えるとビジネスサービス層は厳密にはビジネスロジック（要件に基づいて、データを「情報」へと加工）とサービス（データベースアクセス機能を提供したり、ファイル操作機能を提供したり、機能の提供）に分けてもよいと思います。 [adsense]
思ったより、長い記事になってしまったので続きはまた。
次回はフレームワークを選定していきたいと思います。