web-dev-qa-db-ja.com

Java DDDプロジェクト編成

Java 1つのDDDプロジェクトについて、この種のプロジェクト構造に関する意見を聞きたかっただけです。

com.some.namespace
  application
    services = (app services that talk to repositories and domain model)
    validators = (validators for DTOs in app service layer)
  domain
    events = (domain events)
    exceptions = (exceptions in domain - eg. during validation or business logic)
    factories = (used to construct domain model objects - eg. construct from DTOs)
    model = (full domain model with all entities, value objects etc.)
    repositories = (interfaces only - implemented in infrastruct.)
    services = (domain service interfaces only - implemented in infrastr.)
  infrastructure
    messaging = (message listeners - eg RabbitMQ - talks to app services)
    repositories = (repository implementations)
      sql = (one version of repository implementation)
    rest = (rest endpoints - talks to application services)
    services = (domain service implementations)

メインメソッドを配置するのに適切な場所。インフラストラクチャメッセージングとインフラストラクチャレストは自然に適合すると思いますか？

javadomain-driven-designrepositoryentity
4
Marko Kraljevic

「ドメイン」の部分はドメインを正確に表し、それ以外は何でもないことを常に考えていました。したがって、私にとってのドメインプロジェクトは通常、domain.modelsの下にリストしたもので構成されます（イベントなどは、モデルの一部であり、別個のものではありません）。ドメインはビジネスロジックのみを記述しています...リポジトリとサービスのインターフェースをここに保持しないでください-ドメインを汚染します。

次のようなドメインプロジェクトがあるとします。

domain
    clients
    cases
    matters
    documents
    intakes

（ドメイン内のネストされた各エンティティは、必要に応じてさらに分解されます）。ここでのポイントは、ドメインがビジネスエンティティのみを表し、それ以外は何も表していないことです。 DocumentがファイナライズされたときにXとYが発生する必要があるというビジネスルールの場合（発生方法に関係なく）、DocumentFinalizedイベントはDocumentクラスの一部になります。ドメインの要件を満たしている限り、実装と永続化の詳細はサービスとリポジトリに任せます。

1
jleach