システム開発で思うところ

Javaで主にシステム開発をしながら思うところをツラツラを綴る。主に自分向けのメモ。EE関連の情報が少なく自分自身がそういう情報があったら良いなぁということで他の人の参考になれば幸い

Java EE(JSF)でDDDのようなことを考えてみるための土台

Formに関して色々と考えている中で、部分的に考えるのも良いけれど、一度、ベタで自分なりにJava EEJSF)で、DDDっぽい感じの実装サンプルをつくってみて もうちょっと全体を見渡せるようなものを作ってみた方が、もう少し具体的に考察出来るのかなぁと思うに至りました。

仕様・参考

仕様というか、要件というか、そのあたりについて 参考にさせていただいたものは

GitHub - system-sekkei/isolating-the-domain: Spring Boot : gradle, Spring MVC, Thymeleaf, MyBatis and Spring Security sample

です。

但書

  • 値検証・例外処理・セキュリティ とか全く実装していません。

  • 目下の目的がFormなので、JPA周りも いったん無しで、オンメモリで疑似的なものです。

  • 単純に画面からの入力を 疑似的にCRUDする ざっくりとしたものです。

  • 性能も当然(?)意識していません。

  • 考察のスタート地点としてlombokなど使わずに、ベタで実装したものです。

  • 考察のための入り口なので、これがJSFの普通の実装では確実にありません。*1

構成

過去に考えた、以下をベースに作成しています。

vermeer.hatenablog.jp

vermeer.hatenablog.jp

それ以外の詳細で、見直したところだけを以下に追記します。

Presentation

個々の部品となるFormはサブフォルダでまとめる

当初は、Domainのmodelパッケージと同様に 1つのフォルダに まとめれば良いだろう、と思っていました。
ですが 部品となるFormと画面ルートFormとActionが全て同じパッケージ配下に存在すると クラスが多すぎて わかりにくく感じました。
とりあえず、画面ルートとなるFormとActionというようなScopeを管理するクラスと 個々の部品は別パッケージにしました。
ちょっと悩んだのは、画面ルートとなるForm内で繰り返しの要素として使用するFormです。
部品と言えば部品ですが、集約と言えば集約です。
いったん、Actionなど 画面仕様に特化したものとして 画面ルートとなるFormと同じフォルダに格納しましたが、この辺りは また考え直す可能性があります。

xhtmlは会話スコープ

ブラウザから参照するxhtmlは同一会話スコープとなるものを同じフォルダで管理します。

といっても、今回はConversationScopedではなくSessionScopedを使って手抜きをしています。

ConversationScopedについては、以前 作ったライブラリを適用する形で 後日リファクタリングするつもりです。

とりあえずは、どういう感じで資産を管理するのか、ということを整理するに留めます。

templateを使う

ざっくりとはいえ、今回はtemplateを使って ある程度 JSFの基本的な作りに近しい感じにしました。

各ページの具体的なコンテンツはWEB-INF配下に整理します。

JSFで どの程度 有効なのか分かりませんが Servlet/JSPのように、直接コンテンツとなるxhtmlを参照できないようにしておいた方が セキュリティ的に良さそうに思っているので そうしました。*2

HTML Friendly な実装

xhtmlをEEサーバーを介さず、直接ブラウザで閲覧しても問題なくデザインを確認できるようにしています。

テンプレートエンジンは、thymeleaf だけじゃないですよ、というサンプルくらいには なるかな?と思います。

この後 類似部分について 更に 部品化していくと 結局 EEサーバーを介してデザインを確認しないといけなくはなるのですが、まぁ それは仕方ないかな、と。

とりあえず、初期デザイン時に作成したhtmlを ほとんど そのまま使えるというのは良いですね。

Action

validationもしていません。

仕様に合わない入力をしたら 即例外がスローされます。

今回は、あくまで実装の流れを整理する事だけしかしていません。

Application

特筆することは ありません。

単純なCRUDなアプリにアプリケーションサービスでやることって、RepositoryをCallすることだけ(と、Transaction)だけなんですよね。

Infrastructure

今回はDBを使わず、ダミーテーブル的なインスタンスApplicationScopedで設けました。

とりあえず、Repository周りのイメージを整理することだけをゴールとしています。

Code

Bitbucket

考察

仕様

仕様そのものについてですが、注文・発注など一般ユーザーが使う場合はタスクベースの画面構成であるのは正しいと思います。

ちゃんと2重Submitも制御しないといけない要件だと、この構成にしておかないと事故につながります(つまり正しい構成)。

ただ、自分が求めているのは もっと偏ったエクセルをそのままWebにしたみたいな画面です。

ざっくりいうと、一覧を直接編集して更新する、みたいな画面構成です。

同一画面上で、いくらでも好きなだけ更新もするし、2重Submitなんて気にせず 何度でも上書き更新するような雑な画面です。

もっといえば、大量の項目を入力する なんでも画面です。

最終的なオレオレラッパーフレームワークの仕組みとしては「正しい要件」を満たすのはもちろん、「使用者が限定的な業務システム」もカバーしたいという感じです。

冗長さが半端ない

過剰にも見えるクラス群と、右から左へのデータを写すだけのコードが異常に多いというのが 我ながらの感想です。

このあたりについては、AnnotationProcessorとか コード生成をするか、そもそも方式を含めて見直す必要もあるかも、と思っています。

viewActionが動かない?

なぜか、f:viewActionが動かなかったです。

仕方が無いので、とりあえずf:event type="preRenderView"を使いました。

他の お試し実装をするときには問題なく使えたんだけどなぁ、なんでだろ?

さいごに

まずは、なんとなく、こんな感じかなぁを作りました。

今後は、これに対して 色々と小細工を追加するか、「なんでも画面」のサンプルを先に作るか、どちらにしようかな?

*1:そもそも、JSFは画面単位でManagedBeanを作りましょう、というのが王道のようですから、私のような分割自体が なにそれ?と言われる可能性はあります。ただ、私にとっては こちらの構成の方が 分かりやすいのです。

*2:最終的に生成されるxhtmlの構造はクライアントで確認できるので、どのくらい効果的なのか不明です。