パッケージ構成

DTOがわからんとか、Entityって何よとか、自分の無知ブリを開けっぴろげにさらしてならない今日この頃ですが、僕は元気です。

くーすで触れられていたことでまだgoyaとして言及されていない内容についても、今はgoyaと言った方がいいんでしょうかね。よくわからないのでとりあえずくーすといっておきます。

とにかく、まあパッケージ構成なわけです。

くーすでのパッケージ構成案から始まって、こねくり回して、色々あさっての方向に行ってみたりした結果、結局一周してひがさん提案の構成に近いところに戻ってきました。
ふーむ。

まだプレゼンテーションモデルのパッケージ名やクラス命名規約をどうするかとか細かいところで悩んでますが

  • Entityの種類ごとにmy.entity.foo, my.entity.barとかパッケージ分けたほうがいいのかなとか
  • my.foo.entity, my.foo.logic, my.foo.entityのようにEntityによる区分の法が先に来て、層分け観点はその下にくる方がいいのかなとか (後でパッケージごと再利用するならこっちの方が取り出しやすいかな、と)

などについては、素直にmy.entity配下に全部突っ込めー、という形式がシンプルでわかりやすいだろうと。シンプルさ、わかりやすさが何より重要なんじゃないかと。そういう結論にいったん落としてみました。
再利用するならそのときに抽出しろ!そもそもホントに再利用できるかどうか怪しいんだから、今から心配すんな!ということで。

あと、初期くーすの意志をついで、基本的にEntityはどの層でも利用可能ということで。

でも、ユーザ情報とかをセッションスコープでS2に管理してもらう場合は、Entityそのままってなんか気持ちが悪い気もするんですが、どうなんでしょうか。
気にしないでいいのか、「データをセッションを越えて持ち運ぶために」という新しい文脈でDTOを使ってみるとか。それとも、Session Scope Objectということで、SSOと無理やり呼んでみるとか。