Organizzazione del progetto Java DDD

Question

Organizzazione del progetto Java DDD

#1 da (1 voti)

4

Volevo solo avere opinioni su questo tipo di struttura del progetto in Java per un progetto 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)

Dove sarebbe opportuno mettere i metodi principali. Suppongo che la messaggistica delle infrastrutture e il resto dell'infrastruttura siano naturali?

domain-driven-design java repository entity

posta Marko Kraljevic 17.08.2016 - 23:27

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design java repository entity

Funzioni aggregate in un repository Architettura per l'elaborazione dei dati in tempo reale

score 1 · Accepted Answer

Ho sempre pensato che la parte "dominio" dovrebbe rappresentare con precisione il dominio e nient'altro. Quindi, il progetto di dominio per me di solito consiste in ciò che hai elencato sotto domain.models (eventi e simili fanno parte dei modelli, non qualcosa di separato). Il dominio descrive solo la logica di business ... non conservare le interfacce di repository e di servizio qui - questo è inquinare il dominio.

Potresti avere un progetto di dominio simile a questo:

domain
    clients
    cases
    matters
    documents
    intakes

(ciascuna delle entità nidificate nel dominio sarebbe ulteriormente suddivisa come richiesto, ecc.). Il punto qui è che il dominio rappresenta le entità aziendali e nient'altro. Se è una regola aziendale che quando un documento è finalizzato, X e Y devono accadere (indipendentemente da come accade), quindi un evento DocumentFinalized fa parte della classe Document, così via e così via. Lascia i dettagli di implementazione e persistenza ai tuoi servizi e repository, purché soddisfino i requisiti del dominio.