Goyaについて再考 - 豆無日記

結局きちんと理解しないままだったGoyaですが、せっかくなのでちょびっとだけ考えてみました。全面的に少ない材料(知識と経験)を基にしたオレオレ解釈なのでつっこみどころ満載だと思います。

ドメインオブジェクト＝ DTO + Logic + DAO？

まず、Goyaでは

ドメインオブジェクト ＝ DTO + Logic + DAO

みたいな感じだったのかなぁと。

ドメインオブジェクトをより小さい単位で分割統治することで、

それぞれの役割が明確になり、実装がシンプルになる。
パッケージ構成が明確になり、担当者間での意識ずれが生じにくい。
頻繁に変更が発生する業務ロジックがLogicクラスに抽出されているため、DTO, DAOへの影響がない、または、最低限で済む。

などなどのメリットが生まれると。

ついさっきまでLogic＝Serviceかなぁなんて思ってたりもしましたが、上のように考えるとドメインよりなLogicとは別ものとしてプレゼン層よりなServiceが必要そうですねぇ。

DTOはどのレイヤで使われるべき？

んで、前も悩んでいたこの件については、

DTOがデータ保持に特化した形で分離されたことで、全レイヤのどこでも使ってよい共通オブジェクトとして扱えるようになった。

と考えたらどうだろうと。思いつきですが自分の中ではちょっとしたブレイクスルーかもしれません。これ。

この考えでは、DTOをプレゼンテーションモデルとして使ってもいいし、DAOとの入出力に使っても良いわけです。同一概念のデータを扱う場合はPage(Action)もServiceもLogicもDaoも基本的に同一のDTOクラスを利用すると。
まあよく言われるようにかなりOO的ではない雰囲気満載ですが、その代わりとてもシンプルになる気がします。

自分の中ではOO的かどうかよりも、玉石混淆なメンバで足並みそろえて開発しやすいかどうかが重要なので、シンプルさというのは訴求力が強いです。他に落とし穴がなければ、ですが。

トランザクション境界

ドメインオブジェクトをそのまま使う方式と違い、ただのDTOなのでプレゼン層では余計なロジックを呼び出すことができません。つまり、トランザクション境界はきっちりServiceで分けられます。Open session in viewパターンなんか使う必要がありません。

Dxoの出番は？

プレゼン層での表示ロジックで特に困ることがなければ、DAOで取得したDTOをそのままプレゼン層まで持ち越して使っても良いと思います。
業務ロジックを変更することになってもLogicクラスに分離されてますので、DTOはそのままで各層への影響はほとんどありません。DTOの属性が変更された場合はまあすべての層に影響がでますが、それってドメインオブジェクト方式でも同じじゃありません？

じゃあ、Dxoはどこで使えるのか？
もし、ドメインオブジェクトを使うアーキテクチャであれば、プレゼン層でエンティティを使うべきではないことには激しく同意なので、これはもう断然プレゼンテーションモデル(話の流れ上DPOと言ってみる)を導入すべきです。とすれば、この場合はエンティティ←DXO→DPOという変換にDXOが使われるわけですね。これは異論を挟む余地はないです。

オレ様解釈なGoya的アーキテクチャではどうか。
プレゼン層での表示ロジックの実装の都合上、共通DTOクラスよりも○○なデータ保持形式のDTOの方が扱いやすい。とかなんとか、そういうプレゼン層のわがまま的欲求に答えるためのデータ変換に使うことはあるかもしれないなぁと思いました。
仮にこのような目的のDTOをDPO(Data Presentation Object)と勝手に呼ぶとすると、DTO--DXO→DPO という流れで。
または、プレゼン層でユーザ入力に対するフォームクラスとして、これまた実装上の都合により共通DTOとは異なるDPOを使いたいという場合は、DPO--DXO→DTOと使うことはあるかもしれません。
それ以外の場面では同じDTOクラスをずっと使い回せば事足りると思っています。