パッケージ構成の考察（２）
最新の考察
はじめに
で ベースを考えて 以下の参考プロジェクトを コツコツと肉付けしています。
新しい機能を実装する中で段々と どのパッケージに どのクラスを配置させるのが良いのか混とんとしてきました。
このまま なんとなく続けるのではなく、一旦 手を止めてパッケージの構成を整理することにしました。
概要
以前の考察のメインは青色のところで、今回の考察のメインはオレンジのところ。
実際のパッケージ構成
+---ee
| +---interceptor
| | +---controller
| | +---scope
| | | \---conversation
| | \---validation
| +---jsf
| | +---context
| | +---exceptionhandler
| | \---messages
| \---validation
| \---priority
|
+---example
| \---jsf
| +---application
| | \---service
| +---domain
| | +---model
| | | \---user
| | \---validation
| +---infrastructure
| | \---datasource
| | \---user
| \---presentation
| \---userregistration
| \---form
|
+---spec
+---annotation
| +---application
| \---presentation
| +---controller
| \---view
+---exception
+---interfaces
| +---application
| | \---commnand
| \---infrastructure
+---scope
| \---conversation
\---validation
specパッケージ
spec、つまり仕様を表現するパッケージです。
プロダクトにおける統一的なインターフェースであったり、宣言的実装のためのアノテーションだったりを まとめたものです。
オレオレFWにおける枠組みであり、 特定の技術に極力依存しないようにして、純粋な仕様として可搬性を担保することを意識しています。
例えば依存するパッケージは java.*またはjavax.*に限定するといった感じです。
eeパッケージ
実装のためのパッケージです。
各種ライブラリはプロダクトの infrastructureで ライブラリを直接使用しても良いのですが、毎回つくるのは 面倒です。
specのアノテーションを マーカーとして各種機能を提供したりします。
オレオレFWの実装にあたります。
考察
specにおけるパッケージの命名ルールですが、用途と レイヤーのどちらを先にするのか迷いました。
今回は 用途を先にしてレイヤーを後にしました。
理由はvalidationなどのレイヤーを跨った仕様を扱う際、レイヤーを上位にすると どうもしっくりしなかったからです。
spec.interfacesは、厳密には spec.forproduct.interfacesとかにした方が良いかもしれませんが必要以上に長くなるのも面倒だな、と思って 短くしました。ただ、他のパッケージが増えて来たりする中でコンテキストとして分類しておくべきだと思ったら、spec.forproduct.interfaces または spec.product.interfaces というように サブパッケージを設けるかもしれません。
Code
さいごに
今後もサンプルプロジェクトとして肉付けを続けていきますが、最終的には specパッケージを仕様の集約として、eeパッケージを そのサンプル実装として まとめ上げたいと思っています。
パッケージ構成について、迷いが無いかと言うと、、あります。
ありますが、何を見直すべきか まだ分かりません。
焦らずコツコツ。
