Java

Javaで業務系システムを開発するときの鉄板構成(2015年12月版)

はじめに

Javaにはたくさんのフレームワークやライブラリがあります。

新規のプロジェクトでは何を採用するか検討する必要がありますが、最近Javaを始めた人や長い間レガシーなシステムをやっていて新しい技術に触れる機会がなかった人にとっては、たくさんの候補の中から選択していくのは大変なのではないでしょうか。

そこで、大部分のプロジェクトで無難に対応できるような鉄板ともいえる構成をまとめてみました。

想定システム

  • 業務系システムと呼ばれるもの。金融系、人事系など、比較的お堅い感じのシステム
  • メンバーが複数人で中規模以上のプロジェクト
  • Webアプリ+バックエンドのバッチ

対象外

  • 比較的カジュアルなWebサイト(そういうサイトでJavaを採用する事自体少ないですし)
  • メンバーが一人で個人の趣味でプロダクトを自由気ままに選択できるようなプロジェクト
  • Andoroidアプリ
  • デスクトップアプリ

鉄板構成

自分が鉄板と思う構成は以下の通りです。

JDK

Java8(最新バージョン)

他の言語ではメジャーなバージョンが2つくらいあって、ソースファイルの互換性がなく最新バージョンは対応ライブラリが少ないということがたまにあります。

しかしJavaの場合は古いバージョンで書いたソースやバイナリは、最新バージョンでもほとんどの場合そのまま使えます。

なのでJavaの場合は迷わず最新バージョンを採用しましょう。

IDE

Pleiades All in One

Javaで最も人気のIDEであるEclipseに、日本語化をはじめ様々なプラグインが追加されたものです。
素のEclipseに必要なプラグインをインストールしていくのもいいですが、手間や複数メンバーで同じ開発環境を整えることを考えるとこちらの方が楽です。

その他候補

  • IntelliJ IDEA
    • 補完が賢いなど機能面では優れているようですが、Eclipseと比較して使用者は少なくネット上の情報も少ないので、何か躓いたときに苦労するかも知れません。
  • Spring Tool Suite(STS)
    • EclipseにSpring Framework用の各種プラグインが追加されているIDEです。
    • Springを使うなら必然的にSTS、と言いたいところですが、Springは専用プラグインが必要なほど複雑なフレームワークではないので、個人的にはSTSを使うメリットはあまりないと考えています。

ビルドツール

Gradle

Groovyでスクリプトを記述するビルドツールで、Antのように様々なタスクを自由に記述できます。
かつ、Mavenと同様に規約ベースのビルドツールでもあるので、決められた構成であれば記述量は最小限で済みます。

Mavenと比較すると以下の様なメリットがあります。

  • 規約通りの構成の場合、Gradleのほうが記述量が少ない。
  • 特殊な処理が必要になった場合、MavenはプラグインをJavaで作らなくてはならないのに対して、Gradleはスクリプトの記述のみで対応できる。

既存プロジェクトはMavenを使っているものが多く、その流れで新規プロジェクトでもMavenというケースが多いですが、これからはGradleを使うほうが無難です。

Webフレームワーク

Spring Framework

Springはリリースから10年以上経過していますが、今でも新機能の開発が活発で、Javaの中では最も普及しているプロダクトの一つです。

SpringのコアはDIコンテナとAOPを提供するフレームワークですが、コンポーネントとして様々な機能が提供されていています。
WebフレームワークとしてはSpring MVCを使います。

以前はXMLでの設定が大変でしたが、現在はアノテーションとJava設定クラスでできるようになっており、更にSpring Bootを使うことでシンプルに使う事ができるようになっています。

その他候補

  • Play Framework
    • Ruby on Railsに近いフルスタックフレームワークで、JavaのWebフレームワークの中では現在注目度が一番高いです。
    • フレームワークのコアはScalaで書かれています。
    • まだ発展途上なのでバージョンアップ時に大幅な変更があったりします。中規模以上で長期運用が前提の業務系システムでの採用は慎重に検討する必要があります。
  • Spark Framework
    • RubyのSinatraに近い超シンプルなWebフレームワークです。
    • システム内部の連携用APIなど、小規模で限定した用途であればいいかも知れません。

HTMLテンプレートエンジン

Thymeleaf

最近はバックエンドはJSONを返すAPIだけという事も多く、動的にページを生成するテンプレートエンジンを使う機会はだいぶ減ってきました。

自分自身も最近はテンプレートエンジンを使うことがほとんどないので何がいいのかわからないのですが、Spring MVCと親和性が高いのはThymeleafらしいです。

RDBアクセス

Spring Data JPA

SpringからJPAを使うO/Rマッピングのフレームワークです。デフォルトではJPA実装はHibernateを使用します。

JPAではJPQLやCriteriaAPIを使ってSQLを書かずにクエリーを実装する事ができます。
更にSpring Data JPAでは、命名規則に従ったクエリーメソッドをRepositoryインターフェイスに定義するだけでクエリーが構築できます。

詳しくは以下を参照して下さい。
Spring Data JPA でのクエリー実装方法まとめ

次のようなケースはSpring Data JPAに向いています。

  • データベース設計はシステムに合わせて自由にできる。
  • 各テーブルは必ずユニークキーを持っている。
  • 複合キーを持つテーブルが少ない。
  • シンプルなCRUD操作が多い。

MyBatis(mybatis-spring)

O/RマッピングがテーブルとJavaオブジェクトをマッピングするのに対して、MyBatisはSQLとJavaオブジェクトをマッピングするフレームワークです。
Springから使う場合はmybatis-springを使います。

次のようなケースで向いています。

  • 既存のデータベースを使う。
  • ユニークキーを持たないテーブルが存在する。
  • 複合キーを持つテーブルが多い。
  • 複雑なSQLを使う。

ロギング

ロギングライブラリも色々ありますが、現在最も普及しているのはインターフェイスにSLF4J、実装にLogbackという組み合わせです。

ユニットテスト

JavaでユニットテストといえばJUnitが鉄板ですね。
これにDB操作ではDbUnit、モックにJMockitなどを合わせて使うことが多いです。

ただし、JUnitはテストコードを書くのも読むのも結構辛いです。
最近はGroovyを使うSpockなど、より簡潔に書けるようなものも出始めているので、それらも検討してみるといいかもしれません。

JSON

JSONライブラリで有力なのはJacksonGSONですが、SpringではデフォルトでJacksonを使用します。

CSV

opencsvがよく使われています。
非常にシンプルなライブラリですが困ることはあまりないでしょう。

Excel

Apache POIはExcelやWordを読み書きするライブラリです。

PDF

以前はiTextがよく使わていましたが、最近はApache PDFBoxが有力なようです。

その他

Lombok

Lombokはアノテーションを使用してgetter/setter/toString等のメソッドやBuilderクラス等を自動生成してくれるツールです。
IDEにもgetter/setterを自動生成する機能はありますが、Lombokはコンパイル時にクラスファイルに追加してくれるので、ソースファイルを簡潔に保つことができます。

アプリケーションサーバー

JavaでWebアプリを開発する場合、以前はWarファイルを作成してTomcatなどのアプリケーションサーバーにデプロイして動かすというのが普通でした。

しかし、最近のWebフレームワークは組み込みサーブレットコンテナを使用していてアプリケーション単体で実行できるものが殆どです。

その為、現在はアプリケーションサーバーは必要ありません。(Webフレームワーク次第ですが)

最後に

プロジェクトによって要件は千差万別なので、ここに挙げた構成が適さない場合もあると思います。
そんな時はこちらで他のプロダクトを探してみてください。