モデルの設計

ドメイン、ドメインアプリケーション、ドメインID

W-MSAにおける "ドメイン" とは、関連度の強い複数のモデルを管理するグループを指します。マイクロサービスとして起動・停止する Wagby アプリケーション (wagbyapp) に含まれるモデル群、と解釈することもできます。ドメインごとにビルドされるアプリケーションを "ドメインアプリケーション" と呼びます。

例えば CRM というドメインを用意したとき、その中に顧客モデル、案件モデル、営業訪問記録モデルといった関連するモデル群が含まれるドメインアプリケーションがビルドされます。

1つのドメイン単位で、データベースのトランザクションを設定することができます。つまり、あるモデルのデータを更新したとき、関連する複数のモデルを同時に更新してコミットするという業務の単位となります。

本ガイドでは二つのドメインアプリケーションを用意するものとします。この識別子を "ドメインID" といいます。今回は "app1" と "app2" という二つのドメインIDを用いて説明します。（以降、ドメインIDの部分は、実際に読者が開発したアプリケーションのドメインIDに読み替えてお試しください。）

カスタムドメイン名

次ページで、AWS管理者からカスタムドメイン名を入手する手順を説明します。ドメイン管理者およびドメインアプリケーションの利用者は、ブラウザのアドレスバーに入力するURLに、このカスタムドメイン名を使います。

例えば "wagby.com" というドメインをもった組織が、Wagbyでビルドしたアプリケーションを運用するサブドメインとして "wmsa" を用意したとします。二つのドメインアプリケーション app1 と app2 を利用できるとき、カスタムドメイン名は "app1.wmsa.wagby.com" および "app2.wmsa.wagby.com" になります。(*1)

WagbyDesignerで設定する "ドメインID", "ドメイン名" と、AWSで設定する "カスタムドメイン名" の関係は次の通りです。

ドメインの作成

共通ドメインとシステムドメイン

Wagbyをインストールした時点では、"共通" と "システム" という二つのドメインが用意されています。

共通ドメイン

W-MSAでの運用を行わない、かつ、ドメインという単位でモデルを管理しない場合、開発者はすべての（作成した）モデルを "共通" ドメインに含めてください。

W-MSAで運用する場合、共通ドメインは、複数のドメインで横断して使われるモデルを格納するようにするとよいでしょう。例えば都道府県マスタなどがあげられます。共通ドメインに含まれるモデルは、すべてのドメインアプリケーションに含まれます。

システムドメイン

システムが利用するモデル (juserやjgroupを含む) がすべて含まれています。これも、すべてのドメインアプリケーションに含まれます。

ドメインを作成する

上述した、標準で用意されているドメインとは別に、新しいドメインを作成する方法を説明します。

"モデル" メニューから、"ドメイン" タブを選択します。

ギアアイコンから "新規" を選択します。

"ドメイン名" と "ドメインID" を入力する欄が用意されます。初期状態はいずれも Group1 となっています。

ドメイン名は、W-MSA全体で使う名称です。日本語を含むことができ、任意に命名できます。

ドメインIDは半角英数字で命名します。AWS管理者とやりとりする他、いくつかのケースで利用します。本ガイド全体をとおして、利用箇所を説明していきます。

ここではドメイン名を「アプリケーション1」、ドメインIDを「app1」とします。

モデル一覧に移ると、新しいドメインのタブ「アプリケーション1」が用意されていることがわかります。

モデルをドメインに割り当てる

新しいモデルを作成する

現在、選択されているドメインでモデルを新規作成することができます。作成したモデルは、そのドメインに属することになります。

ここでは顧客モデルを作成してみます。

作成した顧客モデルは「アプリケーション1」ドメインに属します。

共通ドメインタブを開くと、モデルがないことがわかります。すなわち、ドメインごとにモデルの一覧表示が行われます。

所属するドメインを変更する (1) 個別設定

モデルごとに、所属するドメインを変更することができます。"その他" タブを開きます。

現在、選択されているドメインを解除します。

ここでは共通ドメインを選択してみます。

モデル一覧で確認します。"アプリケーション1" ドメインに所属するモデルはありません。

代わって、"共通" ドメインに所属するモデルに、この顧客モデルが表示されるようになりました。

所属するドメインを変更する (2) 一括設定

複数のモデルをまとめて、所属するドメインを変更することができます。

ドメインを変更したいモデルを選択します。

ギアアイコンからドメイン設定を選択します。現在、所属しているドメインがチェックされています。

所属するドメインを変更します。

変更すると、元のドメイン (アプリケーション1) のモデル一覧には表示されないことがわかります。

今回は共通ドメインに設定したため、このドメインの一覧表示に含まれるようになります。

ドメイン割り当てのルール

• 開発者が用意したモデルを "システム" ドメインに所属させることはできません。システムドメインは Wagby 管理用のモデルに限定されています。
• 一つのモデルを（共通ドメインを除く）複数のドメインに所属させることもできます。(*4)
• 共通ドメインに属しているモデルは、他のドメインに属することはできません。
• どのドメインにも所属しないモデル、は用意できません。少なくともいずれかのドメインに所属させるようにしてください。（未指定の場合は "共通ドメイン" となります。）

例

作成したモデルとドメインと、ビルドしたドメインアプリケーションの関係を、次の例で説明します。

ドメインを用意するが、W-MSAを利用しない

ここまでの設定は、ドメインを用意したものの、まだ W-MSA を利用するという設定は行っていません。

この段階で各ドメインにモデルを作成し、ビルドすることができます。この場合、ドメインは（単に）モデルをグループ化して管理するという意味にとどまり、ビルドされるアプリケーションは 1つだけ (wagbyapp) となります。

W-MSAを有効にする

ここまでで、マイクロサービスの単位となるドメインを用意し、モデルをドメインに紐づけたところです。この段階でビルドしても、生成されるアプリケーションは1つ (wagbyapp) だけであり、すべてのモデルが1つのwagbyappに含まれます。

ドメインごとにアプリケーション(wagbyapp)を作成するためには、Wagbyマイクロサービスを有効にします。環境メニューから "サーバ > Wagbyマイクロサービス" を開きます。

設定を有効にすると、次の確認ダイアログが表示されます。

このダイアログに示すように、Wagbyマイクロサービスを有効にすると自動的に以下の設定が行われます。

• HTTPセッションの格納方式が "Spring Session Redis" になる。つまり Redis サーバが必須となる。
• メッセージキューが "ActiveMQ" になる。つまり ActiveMQ サーバが必須となる。
• ロック情報をデータベースのテーブルに格納するようになる。(jfclockobject テーブルが用意される)
• クラスタリング構成は無効となる。（クラスタリング構成を希望する場合、代わりにオートスケールを使うこと)
• プロジェクト識別子は空欄となる。

"セッションID(Cookie)のドメイン設定" については、本ページの後半で説明します。

環境設定

W-MSAを有効にすると、Designerの画面（右上）に "対象ドメイン" の選択肢が表示されるようになります。

（ここではもう一つのドメイン「アプリケーション2」を用意したものとして説明します。）

対象ドメインごとに、環境設定の値を変更することができます。プロジェクト名を（ドメインごとに）設定した例を示します。

* が付与されたタブは、ドメインを横断して共通の値が用いられることを意味しています。

プロジェクト名はドメインごとに指定できますが、"Javaソースコードパッケージ名" は共通です。また、"プロジェクト識別子" は指定することができません。(常にルートデプロイになります。)

"サーバ" タブで説明します。"Javaのバージョン" の設定欄には*が付与されています。これは値を書き換えたとき、他のドメインでも共通に使われることを意味しています。"HTTPセッション" や "認証" の設定も同様です。このように、環境設定は*が付与されていなければドメイン個別に設定でき、付与されていれば共通に用いられるものとなります。

[必須] Spring Session Redis の設定

"環境 > サーバ > HTTPセッション" は Spring Session Redis が選択されています。その詳細を設定します。

[必須] ActiveMQの設定

すべてのドメインアプリケーションで共通に利用する ActiveMQ の設定を行います。

[必須] ドメイン識別子

ドメインアプリケーション同士で、クッキーに含まれるセッションIDに共通の "ドメイン識別子" を含ませることができます。

"セッションID(Cookie)のドメイン指定" に特定の文字列を設定すると、これをドメイン識別子として扱います。

この値は（後述する）転送処理で自動的に付与されます。よってこの設定欄にはダミーの値として "localhost" と記述してください。

[任意] オートスケールの設定

"環境 > サーバ > オートスケール" 欄に用意されている "オートスケールを有効にする" をチェックすると、このドメインアプリケーションはオートスケールで運用することができます。

ビルド

W-MSAが有効なとき、ビルドはドメイン単位で行われます。ドメインを切り替えた直後は、必ずフルビルドを行ってください。

ビルドによって生成されたドメインアプリケーションのフォルダ名は次のようになります。

wagbyapp.<ドメインID>

上の例では、wagbyapp.app1 と wagbyapp.app2 がそれぞれビルドされます。

W-MSAを無効にする

環境メニューから "サーバ > Wagbyマイクロサービス" を開きます。"Wagbyマイクロサービスを有効にする" を解除すると、W-MSA が無効になります。このとき、以下の設定は必要に応じて手動で初期状態に戻すようにしてください。

• "サーバ > HTTPセッション > 格納方式" を空欄にする。
• "アプリケーション > メッセージキュー > メッセージジョブ機能を使用する > ActiveMQ" を解除する。
• "カスタマイズ > 詳細 > ロック情報をデータベースのテーブルに格納する" を解除する。
• "プロジェクト識別子" を設定する。

仕様・制約

メニュー

• 対象ドメインに含まれるモデルだけでメニューを構成します。つまりメニュー設定で、別ドメインのモデルを選択することはできません。
• 各ドメインアプリケーションのメニューには、システムモデルと共通モデルは常に含まれます。メニューの構成(色、並び)も同じです。
• メニュータブの構成（並び）は、すべてのドメインアプリケーションで共通です。
• あるドメインアプリケーションではシステムモデルや共通モデルをメニューに表示させたくない、という要件は、ログオンアカウントの権限で制御してください。
• ドメインをまたぐモデルを操作するためのメニューを用意したい場合は「外部リンクメニュー」を使います。[詳細...]

カスタマイズフォルダ

• ドメインごとに customize フォルダが用意されます。例えば customize.app1 や customize.app2 というフォルダで管理されるようになります。接尾語は "ドメインID" が用いられます。（"内部ドメインID" ではありません。)
• ドメインIDをリネーム（改名）したとき、すでに用意されていた customize.<旧ドメインID> は削除されません。ただしリネームのタイミングで新たに空の customize.<新ドメインID> が作成されます。開発者は手動で旧ドメインID用の customize フォルダの内容を新ドメインID側へコピーし、そののち customize.<旧ドメインID> を削除してください。
• ドメインIDを削除したとき、すでに用意されていた customize.<旧ドメインID> は削除されません。開発者の判断でこれを削除するようにしてください。
• ご注意ください。上の説明からわかるように、W-MSA利用時は customizeフォルダは使われません。customize.<ドメインID>フォルダが用いられます。

外部データベース

• W-MSAはドメイン間でデータベースを共有します。そのため外部データベースの設定は共通で利用されます。あるドメインを選択した状態で外部データベースの設定を変更すると、他のドメインでも同じ変更が適用されます。
• JDBCドライバは各ドメインの customize.<ドメインID> フォルダに配置します。つまり、開発者は同じJDBCドライバファイルをそれぞれの customize.<ドメインID> フォルダにコピーする必要があります。

認証方式

• 認証方式は、すべてのドメインアプリケーションで共通です。（あるドメインアプリケーションだけ OpenID Connect にする、というような指定を行うことはできません。）

クラスタリングとオートスケール

• ドメインアプリケーションにクラスタリングの設定を行うことはできません。オートスケールを設定することはできます。

ログの閲覧

• 標準で提供される "システムログ閲覧" 機能は利用できません。代わって、AWS が提供する CloudWatch Logs のユーザーインタフェースを利用します。

Javaのバージョン

• 複数のドメインでアプリケーションをビルドする場合、および、そのアプリケーションを運用するプラットフォームとしての Java は同じものを使ってください。あるドメインは Java 8 で、別のドメインは Java 11 で、というようなことはできません。
• 同じく、Java のメーカーも同一である必要があります。あるドメインで利用する Java は AdoptOpenJDK で、別のドメインでは OracleJava を使う、というようなことはできません。

リポジトリファイル

• 上述したように、環境設定はドメインごとに変更できる箇所があります。このため、リポジトリフォルダには project_<内部ドメインID>.txt というファイルが用意されます。これはドメイン個別の情報を管理します。"内部ドメインID" は自動で採番される数字です。
• ドメイン間で共通の設定は従来どおり project.txt で管理します。
• ドメインIDを変更した場合 project_<内部ドメインID>.txt は影響を受けません。内部ドメインIDの値は変わらないためです。
• ドメインを削除したとき、project_<内部ドメインID>.txt も同時に削除されます。
• ドメインに関する情報は .domain フォルダ内で管理しています。
• モデルがどのドメインに属するか、という情報は<モデルID>.txt に含まれるリポジトリキーmodel/@domainで管理しています。値は "内部ドメインID" です。
• 開発者は通常、"内部ドメインID" およびリポジトリファイルを直接、閲覧または編集することはありません。そのため Designer を使ってリポジトリを操作しているとき、"内部ドメインID" を直接、意識することはありません。

用語集

このページで登場した用語をまとめます。

ドメイン

複数のモデルを管理するグループの単位です。

ドメインアプリケーション

ドメインを定義したとき、ドメイン単位でビルド処理を行います。ドメイン単位で生成されたアプリケーションをドメインアプリケーションと呼びます。これが1つのマイクロサービスと解釈できます。

マイクロサービス

マイクロサービスは概念的な用語です。W-MSAではマイクロサービスを実装した単位としてドメインアプリケーションという用語を使って説明します。

ドメイン名

W-MSA全体で使う名称です。日本語を含むことができ、任意に命名できます。ビルドしたドメインアプリケーションの管理処理>モデル一覧を参照すると、どのモデルがどのドメインに所属しているかを確認できます。

ドメインID

半角英数字で命名します。AWS管理者に伝えます。ビルドしたドメインアプリケーションの接尾語として、また、カスタマイズフォルダの接尾語として用いられます。

内部ドメインID

システム内部で自動的に採番される数値です。開発者が意識することはありません。リポジトリでは、この内部ドメインIDを用いて管理しています。

共通ドメイン

インストール直後の Wagby に含まれています。開発者が任意のドメインを定義しない場合、作成したモデルはすべて共通ドメインに属します。共通ドメインに属するモデルは、すべてのドメインアプリケーションに含まれます。

システムドメイン

juserやjgroupなど、Wagbyが提供するシステムモデルが属するドメインです。開発者が作成したモデルをシステムドメインに所属させることはできません。システムドメインに属するモデルは、すべてのドメインアプリケーションに含まれます。

AWSカスタムドメイン名

AWSのネームサーバ(DNS)に登録するものです。インターネットで利用できる一意の名前になります。W-MSAで使う「ドメイン名」とは異なる概念です。

セッションID

利用者がアプリケーションにログオンしたときに割り当てられるIDです。ログオンのたびに新しいセッションIDが割り当てられます。ドメインアプリケーション同士で、このセッションIDは共通利用されます。