DDDは、Java Enterprise Applicationsのビジネス中心の設計アイデアであり、複雑なビジネスシナリオに適しています。 1。コアの概念には、エンティティ（一意の識別付き）、値オブジェクト（識別なし、値ビューのみ）、集約（オブジェクト境界）、および倉庫（集約指向アクセスメソッド）が含まれます。 2。階層構造は明確である必要があります。ユーザーインターフェイスレイヤーはリクエストを処理し、ドメインレイヤーはコアロジックを実裝し、インフラストラクチャレイヤーがテクニカルサポートを提供し、ドメインイベントを使用して分離します。 3。スプリングブートと組み合わせると、エンティティとバリューオブジェクトがPojoとしてドメインパッケージに配置されます。リポジトリはインターフェイスを定義し、インフラストラクチャごとに実裝します。ドメインサービスとアプリケーションサービスには、それぞれ@Serviceがマークされています。 4。DDDは、複雑なビジネスロジックを備えたプロジェクトに適しており、複數(shù)のチームが協(xié)力する必要があり、長期的なメンテナンスが必要です。単純なCRUDシステムで使用することはお勧めしません。デザインのアイデアは、最初から標準DDDを強制する代わりに徐々に導入できます。重要なのは、條件を積み上げるのではなく、ビジネスロジックを理解し、責任を明確に分割することです。

DDDは確かにJava Enterpriseアプリケーションで一般的なトピックですが、うまく使用されていません。それは一連のフレームワークやツールではなく、デザインのアイデアであり、コアは、ビジネスをコアとして運転するデザインにあります。プロジェクトのビジネスロジックが複雑で、多くのルールがある場合、DDDはあなたが試す価値がある方向かもしれません。

以下は、いくつかの一般的な質問と使用シナリオに基づいており、Java EnterpriseアプリケーションでDDDを実裝する方法について説明します。

1。コアコンセプトは何ですか？條件に怖がらないでください

DDDには、ドメイン、エンティティ、バリューオブジェクト、集約、リポジトリなどのいくつかのコアコンセプトがあります。これらの用語は學問的に聞こえますが、実際には非常に明白です。

• エンティティ：ユーザーなどの一意の識別を持つオブジェクト。屬性が変更されたとしても、IDが変更されていない限り、それはまだそれです。
• 値オブジェクト：一意の識別子を持たないオブジェクトは、アドレス（アドレス）などの値のみを調べます。アドレスコンテンツが同じである限り、それは同じと見なされます。
• 集約：注文（注文）やラインアイテム（OrderItem）などの関連するオブジェクトの境界のセットは、集約を形成し、ラインアイテムは外部の注文でのみ操作できます。
• ウェアハウジング：データベースアクセスレイヤーではなく、OrderRepositoryなどの集約のための「コレクション」アクセス方法を提供します。

これらの概念を理解することは、より「標準」を書くことではなく、設計時にビジネスロジックをより明確に表現(xiàn)することです。

2。階層構造を設計する方法は？コードを臺無しにしないでください

DDDでは、一般的な層別化は次のとおりです。

• ユーザーインターフェイスレイヤー（アプリケーションレイヤー） ：コントローラーなどのプロセス要求。
• ドメインレイヤー：エンティティ、集約、サービスなどを含むコアロジック。
• インフラストラクチャレイヤー：データベースアクセス、メッセージキューなどのテクニカルサポートを提供します。
• ドメインイベント：注文後の電子メールのトリガーなど、ビジネスロジックを切り離すために使用されます。

たとえば、注文を行うと、コントローラーはアプリケーションサービスを呼び出し、アプリケーションサービスはドメインサービスを呼び出して注文作成を処理し、最終的にリポジトリを介して保存するか、「注文作成が成功する」イベントを公開します。

一般的な誤解：多くの人がリポジトリをDAOとして書いており、DDDの層狀の意味を失うコントローラーでDAOを直接呼び出します。

3.スプリングブーツと組み合わせる方法は？強制しないでください、柔軟になります

Spring BootはDDD向けに設計されていませんが、そのコンポーネント管理メカニズム（@Component、@Service、@Repositoryなど）を使用してDDDの構造を整理できます。

• エンティティとバリューオブジェクト：注釈なしで、ドメインパッケージに入れます。
• 集計ルート：通常、エンティティでは、@Aggregateアノテーション（Axonおよびその他のフレームワークを使用する場合）を追加できますが、通常は追加できません。
• リポジトリ：インターフェイスで定義されているため、実裝はインフラストラクチャパッケージに配置し、JPAまたはMyBatisを使用して実裝できます。
• ドメインサービス：@Service Annotationを使用して、ドメインパッケージに入れることができます。
• アプリケーションサービス：@Serviceを使用しますが、アプリケーションパッケージに入れます。

構造例：

 com.example.order
├├）。アプリケーション
│└│。。RoderApplicationService.java
domain。ドメイン
│├├。Java（エンティティ）
││クアーサービス。Java（ドメインサービス）
││クアーRepository.java（インターフェイス）
└··ックスインフラストラクチャ
    └└リン

注：スプリングスキャンサブパッケージはデフォルトで行われるため、パッケージ構造が合理的であることを確認し、春に豆を見つけないようにしてください。

4。DDDはいつ適切ですか？大したことをしないでください

DDDは全能ではなく、以下により適しています。

• 複雑なビジネスロジックと変更ルールを備えたシステム
• 複數(shù)のチームワークと統(tǒng)一言語を必要とするプロジェクト
• 長期的なメンテナンスと明確な構造を備えたシステムが必要です

ユーザー管理やロギングなどのCRUDシステムを構築するだけで、DDDを使用すると複雑さが高まります。

提案：単純な「貧血モデル」から始めて、最初に集約や倉庫の導入やフィールドサービス、イベントなどを導入するなど、ビジネスの複雑さが増加した後、DDDの概念を徐々に導入できます。

DDDは一晩では達成されておらず、設計の徐々に進化しています。重要なのは、用語ではなくビジネスを理解することです。明確な構造と明確な責任は、「DDDのように見える」よりも重要です。

基本的にそれだけです。

以上がJava Enterpriseアプリケーションのドメイン駆動型設計（DDD）の詳細內(nèi)容です。詳細については、PHP 中國語 Web サイトの他の関連記事を參照してください。