Startup as Single Project

スタートアップの概要

Exampleを元にして、新しいプチBlankプロジェクトを作ります。

ここでは、一つだけのWebアプリケーションを想定します。

将来、同じデータベースに対して、管理側のWebアプリを作ったり、バッチや別の顧客のためのアプリを追加するかもしれないのであれば、 こちらではなく、マルチプロジェクト構成の方のスタートアップをオススメします。(あとで構成変更するのは大変なので)

スタートアップの手順

流れは以下のような感じです。

  1. Exampleプロジェクトを準備
  2. ドメインとサービス名を決める
  3. プチBlankプロジェクトを作成する
  4. とりあえず動かしてみましょう
  5. #change_it_first で検索
  6. DB設計、そして自動生成
  7. #change_it で検索

1. Exampleプロジェクトを準備

シングルプロジェクトのExampleである、harbor を clone します。

プロジェクト
harbor
Gitリポジトリ
https://github.com/lastaflute/lastaflute-example-harbor.git

2. ドメインとサービス名を決める

新しく作るサービスの、ドメインとサービス名を決めます。

例えば、LastaFluteのExampleプロジェクトであれば、このようになっています。

ドメイン
docksidestage.org
サービス名
harbor

実際は、サービスがドメイン名に組み込まれることが多いので、その場合は...

ドメイン
docksidestage.org
サービス名
docksidestage

となるでしょう。

あとで直すのは大変なので、慎重に決めてください。

ただ、開発を始める時点では、ドメインもサービス名もまだ決まってないこともあるでしょう。 そのときは、いわゆるコードネーム、内部向けのプロジェクト名を付けるほかないでしょう。

3. プチBlankプロジェクトを作成する

ドメインとサービス名を書き換え

StartupTest.javaにて、ドメインとサービス名の値を書き換えます。

StartupTestを実行

そして、そのクラスのJUnitのテストを実行します。すると、Exampleプロジェクトと同じ階層のディレクトリに、 指定されたドメインとサービス名の新しいプチBlankプロジェクトが作成されます。

開発用workspaceでセットアップ

それを、開発用のworkspaceに移動して、Eclipseなどで import して、コンパイルしましょう。

Eclipseで新しい workspace であれば、もろもろの workspace の設定をしておきましょう。 Java Editor Templates も、この時点で設定しておきましょう。

開発環境の構築 | LastaFluteの実装チュートリアル

説明のために、例えば...

この後の説明では、新しいドメインは dancingdb.org, サービス名は mythica と仮定します。

たとえばドメイン
dancingdb.org
たとえばサービス名
mythica

4. とりあえず動かしてみましょう

データベースはH2?

もし、別のデータベースであっても、いったんはそのまま進みましょう。ひとまず動く環境を作ってから変更すると良いでしょう。 (修正すべきファイルは何か?など、後のステップで登場します)

まずは ReplaceSchema

まずは ReplaceSchema, テーブルはExampleのままですが、新しいスキーマ名で作成されます。

そして、Bootクラスでmain()実行

そして、MythicaBootというクラスの main() を実行すると、Jettyが起動します。 起動ログの最後に表示される url をブラウザからアクセスしてみましょう。ひとまず、何かしら画面が表示されればOKです。

5. #change_it_first で検索

プロジェクト全体を、#change_it_first で grep します。

これは、プロジェクト環境を作ったときに真っ先に直すべき箇所に記載されています。 その部分のソースコードをよく読み、自分のプロジェクトではどうするかしっかり考えて直しましょう。

直したときは、#change_it_first コメントを削除しましょう。 すぐに決められないものとかあった場合、あとで何を直して何を保留したのかがわからなくなってしまうので。

ここでは、代表的なものを紹介します。

セキュリティ設定

パスワードやCookieなどの暗号化のための秘密鍵を設定します。

MythicaFwAssistantDirectorクラスにて、InvertibleCryptographerを構築している箇所が 二箇所 あります。 それぞれに、アルゴリズムと秘密鍵を設定します。秘密鍵をどこから持ってくるか、どう定義するかはご自由に。

アプリ種別情報

MythicaBaseActionクラスにて、APP_TYPE と USER_TYPE を定義します。

APP_TYPE
アプリの種別、mythicaなら MYC など三文字(推奨)のコード
USER_TYPE
ログインユーザの種別、会員(member)なら M など一文字(推奨)のコード

これらは、共通カラムやログなどで利用されます。 間違っていてもアプリの動作に影響はほとんどありませんが、運用時のトレース情報として重宝します。 また、これらの値をアプリで独自に利用してもよいでしょう。

Boot情報

MythicaBootクラスにて、アプリのポート番号やコンテキストパスを調整します。

もちろん、デフォルトのままでよければ、そのままでOKです。

6. DB設計、そして自動生成

もし、DBを MySQL から別のDBMSに変更するなら

以下の設定ファイルを修正します。

basicInfoMap.dfprop
databaseプロパティ
databaseInfoMap.dfprop
JDBC接続情報
mythica_env.properties
JDBC接続情報
pom.xml
dependenciesのJDBCドライバ
.erm (ERMaster-bなら)
ERMaster-bの対象データベース

最初のDB設計

DB設計します。

とはいっても、全部いっきにやるのではなく、開発の第一歩が踏める程度の最低限のシンプルなものだけにしましょう。 暫定のテーブルでもOKです。あとで直して再自動生成してしまえばいいだけなので。

最初の自動生成

できたら、DBFluteで自動生成をして、アプリに適用させます。 コンパイルエラーになるところは適宜アプリにフィットさせていきましょう。さあ、ここから開発の始まりです。

7. アプリにフィットさせていく

ひたすらフィット

ここからは、動かしながら気付いた点をひたすらアプリにフィットさせていきます。

#change_it で検索

今度は、#change_it で検索してみます。

自動生成でコンパイルエラーになった時点で、すでに直しているところもあるかもしれませんが、 すぐに修正しなくてもいいけど、いつかはちゃんとアプリにフィットさせないといけない場所に記載されています。

こちらも、#change_it_first のときと同様に、直したら削除しましょう。 直したけど、まだ後で調整が必要(かも)というときは、(Eclipseなら _to => ctrl+space で補完して)todoコメントを入れましょう。

Bon voyage

ExampleのデフォルトのままでOKか、現場フィットが必要かどうか、わからないところはたくさんあります。 Trial & Error をしながらフィットさせていってください。