パッケージ別フィーチャー規約を使用してフレームワーククラスを配置する場所

Question

私はpackage-by-feature命名規則について多くのことを読んできました。だから私は新しいプロジェクトでそれを試してみることにしました。しかし、私は大クラスのクラスでどのように使用されるべきなのかわかりません。たとえば、SpringとHibernateのような巨大なフレームワークを使っているからです。

そして、我々のdatabaseアクセスクラス、そうで接続を管理し、1：

これが私たちのSpring contextsクラスを処理する方法です。

私はこれについて草案をしました：のように、これらのフレームワークのための共通のパッケージを使用して：

com.company.project.common.spring 
com.company.project.common.database 

しかし、私はこれはまだpackage-by-layerビットのように見えることを恐れています。 :) feature classesでアクセスするパッケージはどのように作成する必要がありますか？

Answer 1

一般的な推奨事項は「レイヤーではなく機能別パッケージ」です。私がしばしばしているのは、機能別パッケージ、、次にレイヤーです。私はまた、トップレベルのパッケージは "機能"ベースであるべきだと考えています（機能コンポーネント、それは何でも）。しかし、私はまた、私のレイヤーをサブパッケージに分けたいと思っています。

フレームワーク関連のコードは、「問題のドメインの重要な高水準な側面」のように、「機能」を構成するものではないため、パッケージごとにあまり機能しませんここで感覚。しかしそれでも、これは重要なコードなので、構造化のアプローチが必要です。私は私が使用しているライブラリを拡張したり、強化する必要がある場合は、私はパッケージがライブラリのパッケージ構造に並列構造、

：

私は通常、二つのアプローチを使用しています。たとえば、Spring用の新しい数値フォーマッタを実装する必要がある場合は、おそらくcom.acme.foo.springframework.format.numberというパッケージ名をorg.springframework.format.numberという名前にします。

しかし、フィーチャのレイヤに共通の基本クラスを実装する必要がある場合、これはおそらくcom.acme.foo.common.<layer>のようなものになります。たとえば、ある機能のデータアクセス層にcom.acme.foo.<feature>.dataaccessのパッケージがある場合、com.acme.foo.common.dataaccessはすべての機能のデータアクセス層の基本クラスを保持できます。

両方のアプローチが並行して使用されます。あるクラスがフレームワークかライブラリ拡張かどうか（このプロジェクトの外で使うことは想像できますか？）、またはプロジェクトのレイヤーに近いかどうかを判断するだけです。