「パッケージってフォルダ分けでしょ？」
そう思っていませんか？
実はここが落とし穴です。
Javaにおけるパッケージ設計は、
アーキテクチャの土台です。
ここを間違えると、
- 修正のたびに広範囲へ影響
- どこに何があるかわからない
- 新人が入れないプロジェクト
- 将来モジュール化できない
という状態になります。
この記事では、
Javaのパッケージ設計で見落としがちなNGパターンを徹底解説します。
初心者にもわかるようにやさしく。
でも内容は実務レベルです。
そもそもパッケージ設計とは何か？
パッケージは単なるディレクトリではありません。
「責任のまとまり」
です。
クラスの集まりではなく、
役割の集まりです。
ここを意識できるかどうかで、
エンジニアとしてのレベルが大きく変わります。
NGパターンその一：レイヤーだけで分ける構成
よく見る構成です。
com.example.controller
com.example.service
com.example.repository
一見きれいです。
でも問題があります。
なぜダメなのか？
ユーザー機能を修正するとします。
すると、
- controller
- service
- repository
全部を行ったり来たりします。
つまり、
機能単位でまとまっていないのです。
改善例：機能単位でまとめる
com.example.user
├─ UserController
├─ UserService
├─ UserRepositorycom.example.order
├─ OrderController
├─ OrderService
├─ OrderRepository
こうすると、
- ユーザー関連は全部 user 配下
- 注文関連は全部 order 配下
になります。
読みやすさが劇的に向上します。
NGパターンその二：common / util ごみ箱
これ、本当に多いです。
com.example.common
com.example.util
最初は便利。
でもすぐにこうなります。
- 何でも入る
- 依存の中心になる
- 削除できない
なぜ危険か？
commonが多くのパッケージから参照されると、
変更が極端に難しくなります。
依存のスパゲッティ化です。
改善方法
本当に共通かを問いましょう。
- それは複数の機能で再利用されている？
- ドメインをまたいでいる？
共通ではなく、
「user専用共通」なら user パッケージに入れるべきです。
NGパターンその三：DTOだけを集める
com.example.dto
これもよくあります。
しかし、
そのDTOはどの機能のため？
が見えません。
改善例
DTOも機能ごとに置きます。
com.example.user.dto
Javaはパッケージ階層が明確なので、
意味を持たせやすいのが強みです。
NGパターンその四：循環依存
これが最も危険です。
Aパッケージ → Bパッケージ
Bパッケージ → Aパッケージ
設計が崩壊します。
なぜ問題か？
- 変更影響が読めない
- テストが壊れやすい
- モジュール分割ができない
改善方法：依存逆転
// userパッケージ
public interface UserRepository {
void save(User user);
}
// infrastructureパッケージ
public class UserRepositoryImpl implements UserRepository {
@Override
public void save(User user) {
// DB処理
}
}
抽象に依存させます。
Javaのinterfaceは、
パッケージ設計の最強武器です。
NGパターンその五：巨大パッケージ
com.example.domain
中にクラスが大量。
何でも入る状態。
これは実質「単一フォルダ」です。
改善方法
サブパッケージに分けます。
com.example.domain.user
com.example.domain.order
単一責任を守りましょう。
NGパターンその六：public乱用
とりあえずpublic。
危険です。
publicにすると、
どこからでも参照可能になります。
正しい考え方
- まずは修飾子なし（パッケージprivate）
- 本当に外に見せたいものだけpublic
Javaはこの制御が強い言語です。
これが大きな優位性です。
NGパターンその七：ビジネスが見えない名前
logic
impl
helper
これでは意味がありません。
良い例
billing
subscription
inventory
ドメイン用語を使いましょう。
コードが仕様書になります。
NGパターンその八：テストを考えない構成
テストしづらい構成は、
設計が悪い証拠です。
モジュール境界を意識すれば、
テストも簡単になります。
NGパターンその九：将来のモジュール化を無視
今は単一プロジェクト。
でも将来、
- マルチモジュール
- JPMS
にしたくなるかもしれません。
そのとき困らないように、
境界を意識しておきましょう。
Javaはモジュール化との相性が非常に良い言語です。
良いパッケージ設計の例
シンプルな例です。
com.example.user
├─ domain
├─ application
├─ infrastructure
├─ presentation
クリーンアーキテクチャ風です。
全部完璧にやらなくてもいい。
まずは意識することが大切です。
Javaだからこそできる強い設計
Javaの強みは、
- 静的型付け
- interface
- パッケージprivate
- 成熟したIDE
です。
境界を強く表現できる。
これは大きな優位性です。
設計できるJavaエンジニアは強い
転職市場では、
- コードが書ける人
より - 設計できる人
が評価されます。
パッケージ設計はその第一歩です。
独学を始めるなら
まずは基礎を固めましょう。
絶対にJavaプログラマーになりたい人へ。
https://amzn.asia/d/3E1CYbv
基礎が固まれば、設計も理解できます。
本気で設計力を伸ばしたいなら
- コードレビューを受けたい
- 設計の正解を知りたい
- 転職サポートも欲しい
そんな人はサイゼントアカデミー。
実践レベルのJava設計力を身につけられます。
まとめ
Javaのパッケージ設計で見落としがちなNGパターンは、
- レイヤーだけ分割
- commonごみ箱
- DTO集約
- 循環依存
- 巨大パッケージ
- public乱用
- 意味のない名前
- テスト軽視
- 将来設計無視
です。
いきなり完璧を目指さなくていい。
まずは一つ、
NGを潰すことから始めましょう。
それが、
「ただのJavaコーダー」から
「設計できるJavaエンジニア」への第一歩です。
あなたの成長を、心から応援しています。
コメント