web-dev-qa-db-ja.com

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プロジェクト/モジュールが大幅に増え、データベースを生成するクラスが複数のプロジェクトに分散されることになります。誰かが各アプローチの長所/短所をアドバイスできますか？

javaeclipsespringhibernatemaven
16
Steve Chambers

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

パッケージ構造でテクニカルレイヤーを適用しようとすると、アプリケーションで多くのエンタングルメントが発生します。言うまでもなく、サービスインターフェイスの背後にあるすべてのものを隠すために一生懸命に取り組んでいることは言うまでもありません。（主にパッケージ化のため）最初に行うことは、すべてをpublic classにすることです。これは、x.y.z.serviceパッケージとx.y.z.repositoryパッケージの間に技術的な分離があり、すべてがリポジトリーにアクセスできるようになると、困難になります。ブームがサービスレイヤー内にカプセル化されます。

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

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

Oliver GierkeがJavaでコンポーネントを一緒にパッケージ化することについて いい投稿 を書いています。 Simon Brownはこのテーマについてさらに 一般的な話 を書いています。

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

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

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

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

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

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

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

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

最終メモ

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

免責事項

はい、すべてを1つのモデルにまとめようとしました。また、アプリケーションで技術的な分離を使用しようとしました。ただし、エンタングルドアプリケーションレイヤーの作成に関する2、3年の経験の後（最初は良い考えのように思われ、その後アプリケーションが成長し始めます...）別の方法があるはずだと思いました。

リンク集

  1. クリーンアーキテクチャ、ボブマーティンおじさん
  2. Hexagonal Architecture（aka Ports and Adapters）、Alistair Cockburn
  3. 私のアーキテクチャはどこへ行きましたか、Oliver Gierke
  4. OODの原則、ボブマーティンおじさん
  5. DDDを適用する際の誤り、ウディダハン
  6. 境界付きコンテキスト、Martin Fowler
  7. 建築上明白なコーディングスタイル、Simon Brown

本

  1. 成長するオブジェクト指向ソフトウェア、テストによるガイド
  2. Javaアプリケーションアーキテクチャ：OSGi（Robert C. Martinシリーズ）を使用した例のあるモジュール化パターン
  3. ドメイン駆動設計：ソフトウェアの心臓部の複雑さに取り組む
  4. 開発者向けソフトウェアアーキテクチャ
  5. ドメイン駆動設計の実装
31
M. Deinum