Java DDD project organization

Question

Just wanted to hear opinions on this kind of project structure in java for one DDD project:

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)

Where would be appropriate to put main methods. I suppose infrastructure-messaging and infrastructure-rest would be natural fit?

Answer 1

I've always figured that the "domain" portion should accurately represent the domain, and nothing else. So, the domain project for me usually consists of what you have listed under domain.models (events and such are part of the models, not something separate). The domain describes only the business logic... do not keep repository and service interfaces in here - that's polluting the domain.

You might have a domain project that looks like this:

domain
    clients
    cases
    matters
    documents
    intakes

(each of the nested entities in the domain would be further broken down as required, etc). The point here is that the domain represents the business entities and nothing else. If it's a business rule that when a Document is finalized, X and Y must happen (regardless of how it happens), then a DocumentFinalized event is part of the Document class, so on and so forth. Leave the implementation and persistence details up to your services and repositories, so long as they're satisfying the domain requirements.