パッケージ構成検討

パッケージ構成の考え方

パッケージ構成については「必ずこうすればよい」というやり方があるわけでありませんが、基本となる考え方はあります。 プロジェクトの特性に合わせてパッケージ構成を考えます。

基本は分業しやすいようにパッケージ構成を決めるのが望ましいです。
プロジェクトの体制を考慮してパッケージごとに担当者を割り振れるようにするなど、成果物の責任範囲が明確になるよう分割すると開発が進めやすくなります。

パッケージ構成を考えるうえで、大きく以下の2つ（ないし、その組み合わせ）のやり方があります。

  • 業務的な機能で分割
  • クラスの役割で分割

例として「会員管理システム」に以下のような業務機能を持つとします。

業務名 パッケージ名
入会 enrollment
属性変更 settings
ポイント point

業務的な機能での分割例

業務的な機能で分割した場合、以下のようになります。

  • com.example.member
    • enrollment
      • XXXAction
      • XXXForm
      • XXXDto
      • YYYAction
      • YYYForm
      • YYYDto
      • ZZZService
    • settings
      • （略）
    • point
      • （略）

プロジェクトで開発する場合、業務的な機能のまとまりで分担を行うことがよくあります。 例えば、以下のような分担があります。

  • xxxサブシステムはA社担当
  • yyy機能はBさん担当

この場合、業務的な機能でパッケージを分割するとパッケージ配下にその担当者の成果物だけが格納されるので、分業、並行開発が行いやすくなります。
例えば、パッケージ配下に使用されないクラスが見つかった場合、そのパッケージの担当者が責任を持ってクラスの要否を検討し削除する必要があります。

ただし、パッケージの粒度が大きすぎる場合、1つのパッケージに格納されるクラスが多くなりすぎて開発が進めにくくなります。 このような場合は、パッケージを複数階層に細かく分けることで、1パッケージ内のクラス数を抑えることができます。 例えば「入会」業務の機能が膨らんできた場合は、入会/審査や入会/キャンペーンのように階層を作ります。

クラスの役割での分割例

クラスの役割で分割すると以下のようになります。

  • com.example.member
    • action
      • XXXAction
      • YYYAction
      • （略）
    • form
      • XXXForm
      • YYYForm
      • （略）
    • dto
      • XXXDto
      • YYYDto
      • （略）
    • service
      • ZZZService
      • （略）

この構成の場合、いわゆるレイヤードアーキテクチャが実現しやすくなります。 あまり一般的ではないですが、業務的な機能ではなくレイヤーで担当を割ることがあります。 （プレゼンテーション担当とドメイン担当のように） このような場合は、クラスの役割でパッケージを分割することで分業が進めやすくなります。

システム規模が大きくなりすぎると、パッケージ内のクラスが多くなりすぎで開発がやりにくくなります。 このパッケージ構成のままではこの問題は解決できないので、大規模プロジェクトはこの構成は避けたほうが無難です。

クラスの役割 – 業務的な機能 での分割例

上記2つを組み合わせることも可能です。

  • com.example.member
    • action
      • enrollment
        • XXXAction
        • YYYAction
      • settings
        • （略）
      • point
        • （略）
    • form
      • enrollment
        • XXXForm
        • YYYForm
      • settings
        • （略）
      • point
        • （略）
    • dto
      • XXXDto
      • YYYDto
      • settings
        • （略）
      • point
        • （略）
    • service
      • enrollment
        • ZZZService
      • settings
        • （略）
      • point
        • （略）

この場合、Actionクラスが1つのパッケージに集約されます。com.example.member.actionをルートパッケージに指定できるので、Nablarchのルーティング設定も記載しやすいです。

業務的な機能 – クラスの役割 での分割例

一見良いように見えますが、actionパッケージが複数できてしまうため、Nablarchのルーティング設定で扱いにくくなります。 無理に扱おうとするとURLが長くなるというデメリットがあります。

  • com.example.member
    • enrollment
      • action
        • XXXAction
        • YYYAction
      • form
        • XXXForm
        • YYYForm
      • dto
        • XXXDto
        • YYYDto
      • service
        • ZZZService
    • henkou
      • action
      • （略）
    • point
      • （略）