Javaアプリケーション構造：水平分割と垂直分割

大きなJavaアプリケーションのプロジェクト構造（Maven / Eclipseを使用）の開始について少し議論します。

オプション1：

entities (i.e. the whole database using Hibernate classes-first)
services (i.e. sets of read/write operations on the entities)
app (perhaps split up more further down the line)

オプション2：

area1-entities
area1-services
area1-app
area2-entities
area2-services
area2-app
...
(where area1, area2 etc. are functional areas of the system)

オプション2を使用すると、明らかにMavenプロジェクト/モジュールが大幅に増え、データベースを生成するクラスが複数のプロジェクトに分散されます。誰もが各アプローチの長所/短所をアドバイスできますか？

どちらもしないことをお勧めします。

パッケージ構造を使用して技術的な階層化を強制しようとすると、アプリケーションに多くの絡み合いが生じます。サービスインターフェイスの背後にすべてを隠そうと努力していることは言うまでもなく、最初に行うこと（ほとんどがパッケージングによる）はすべてをaにすることpublic classです。パッケージx.y.z.serviceとx.y.z.repositoryパッケージが技術的に分離されている場合、これは苦痛になり、今ではすべてがリポジトリにアクセスできます。ブームは、サービスレイヤー内にカプセル化されます。

代わりに、より機能的でタマネギベースのアプローチ（クリーンアーキテクチャ、六角形アーキテクチャ）に従う必要があります。これは、単一責任の原則（パッケージに適用される場合）およびパッケージングの原則にも適合しています。

1. 一緒に変化するものは一緒にパッケージ化されます
2. 一緒に使用されるものは一緒にパッケージ化されます

Oliver Gierkeは、Javaでのコンポーネントのパッケージ化に関する素晴らしい投稿を書いています。サイモン・ブラウンはもっと書いた、このテーマに関する一般的な物語を。

アプリケーションのコアを保持するために、次のようなコアパッケージ構造を目指しています。

x.y.z.area1
x.y.z.area2

これで、たとえばWebサービス用のwebサブパッケージ、wsまたはそれrestだけを保持するパッケージを追加するWebインターフェイスがある場合。基本的にコアに接続します。

x.y.z.area1.web
x.y.z.area1.ws
x.y.z.area2.rest

これで、コア内部から他のレイヤーにオブジェクトを再利用することを検討できますが、そのレイヤーには特定のドメインを使用する方が良いでしょう。同様に、オブジェクトからSQLへのマッピングと同様に、画面に表示したり、WebサービスでXMLとして使用したり、ビジネスロジックを実装する方法に（多くの場合）不一致があります。ビジネスおよびWebドメインの複雑さに応じて、それらを接続する必要のある、基本的に2つの異なる境界コンテキストを解決するための別個の問題ドメインと見なすことができます。

CQRSリソースからの引用を使用するには

単一のモデルを使用してトランザクションを検索、レポート、および処理するための最適なソリューションを作成することはできません。

すべてを単一の（ドメイン）モデルに入れ、責任を分離しようとしないでください。おそらく、より多くの（より小さい）クラスになりますが、アプリケーションのレイヤー間の分離はよりクリーンになります。

最終ノート

アーキテクチャの作成は、あるソリューションと他のソリューションのトレードオフを決定することを忘れないでください。これは、ドメインの複雑さに大きく依存し、主にアプリケーションの機能要件によって決定される必要があります。ただし、非機能（パフォーマンス、セキュリティ）および環境の制約（使用する言語、プラットフォーム、経験）の影響を受けます。また、コーディングなどのアーキテクチャは、新しい要件ごとに終了することはなく、アプリケーションの再設計につながる可能性があります（そうすべきですか？

免責事項

はい、すべてを単一のモデルに入れようとしました。また、アプリケーションで技術的な分離を使用しようとしました。しかし、絡み合ったアプリケーションレイヤーを作成するための数年の経験の後（最初は良いアイデアのように思えますが、アプリケーションは成長し始めます...）、別の方法が必要だと考えました。

リンク集

1. クリーンアーキテクチャ、ボブマーティンおじさん
2. 六角形アーキテクチャ（別名ポートおよびアダプター）、Alistair Cockburn
3. 私の建築はどこへ行ったのか、オリバー・ジールケ
4. OODの原則、ボブ・マーティンおじさん
5. DDDを適用する際の間違い、Udi Dahan
6. 有界コンテキスト、マーティン・ファウラー
7. 建築的に明白なコーディングスタイル、サイモンブラウン

本

1. テストに導かれたオブジェクト指向ソフトウェアの成長
2. Javaアプリケーションアーキテクチャ：OSGiを使用した例によるモジュラリティパターン（ロバートC.マーティンシリーズ）
3. ドメイン駆動設計：ソフトウェアの中心にある複雑さへの取り組み
4. 開発者向けのソフトウェアアーキテクチャ
5. ドメイン駆動設計の実装