DDD e CQRS danno senso per un'applicazione che è principalmente immissione di dati e rapporti

Question

DDD e CQRS danno senso per un'applicazione che è principalmente immissione di dati e rapporti

#1 da (1 voti)
#2 da (0 voti)

4

Al momento abbiamo 2 applicazioni PHP che non condividono assolutamente alcun codice, ma condividono un database comune. Un'app è l'applicazione della scheda attività per gli amministratori, l'altra è la scheda attività che i dipendenti registrano il loro tempo rispetto ai progetti. Stiamo proponendo una ricostruzione completa dell'applicazione utilizzando Spring Boot, Spring Data Jpa, Hibernate, Java8. Vogliamo mantenere separate le applicazioni in quanto l'azienda potrebbe voler implementare e apportare modifiche in modo indipendente e presentare e prendere anche dati diversi, quindi non ha senso condividere comunque gli stessi modelli e API.

Le applicazioni non hanno ancora molte regole di business complesse, il sistema è metà entrata dati e metà segnalazione. Tuttavia nel tempo ci sono più funzionalità gestite manualmente che vogliamo essere nel sistema. Come tale vorrei prendere in prestito alcune delle idee di DDD e CQRS nel design.

La mia proposta è una soluzione Maven multi modulo

-- Timesheet (parent module)
  -- timesheet-core
    -- domain services
    -- repositories
    -- domain models / jpa entities
    -- other common logic and classes
  -- timesheet-web-admin
    -- controllers / rest endpoints
    -- services (will query from here for read operations, writes go through repositories)
    -- DTOs (used to move data between client and other layers)
  -- timesheet-employee-admin
    -- controllers / rest endpoints
    -- services (will query from here for read operations, writes go through repositories)
    -- DTOs (used to move data between client and other layers)

Non sono uno che crede nel seguire rigorosamente schemi come una dottrina / religione. Penso che le idee e i modelli di DDD e CQRS potrebbero essere comunque utili. Abbiamo circa 100-120 persone che utilizzano questo sistema, quindi non sono sicuro che l'event sourcing e la creazione di database separati siano realmente necessari.

Questo design / architettura ha almeno un senso da un alto livello o sto facendo un terribile errore cercando di portare DDD nell'ovile? La mia idea è che JPA / Repository gestirà tutte le operazioni di scrittura, ma i servizi di applazione gestiranno le letture e restituiranno i dati negli oggetti DTO.

design domain-driven-design web-services cqrs

posta greyfox 02.03.2017 - 18:03

fonte

2 risposte

Leggi altre domande sui tag design domain-driven-design web-services cqrs

Strategia di ramificazione per lo spostamento del ramo di funzione tra le versioni Utilizzo di Makefile come repository di script

score 1 · Answer 1

Attualmente sto lavorando su un'applicazione che fa anche un po 'di tempo per riferire. Non è mai sembrato essere un'applicazione di "solo immissione e segnalazione di dati".

DDD o no non è ciò che decidi guardando lo spazio della soluzione da solo. Dovresti uscire dalla zona di comfort degli sviluppatori e trascinarti nello spazio del problema, iniziare a parlare con il tuo cliente, il che significa che sono i tuoi esperti di dominio. O questo potrebbe essere il proprietario del prodotto. Non appena smetti di parlare di immissione e visualizzazione dei dati, potresti trovarti da qualche parte.

Se utilizzi tecniche come Event Storming quando registri queste discussioni, potresti scoprire qualche comportamento nel tuo dominio e potrebbe essere piuttosto complesso. Qualcuno potrebbe dire che è una complessità non necessaria, ma non fare errori: la complessità accidentale è completamente diversa dalla complessità del dominio reale. Certo, alcuni casi limite potrebbero non richiedere l'automazione e possono essere risolti felicemente con un semplice intervento umano, ma alcuni potrebbero essere molto frequenti.

Una cosa su cui riflettere è il registro di controllo, in genere le persone vogliono vedere come le voci temporali fluiscono attraverso il sistema. Nessun corpo vuole vedere la propria scheda attività modificata da qualcun altro senza sapere perché, quando e perché.

Il processo di approvazione potrebbe essere abbastanza complesso.

Ciò che intendo è che la tua soluzione sembra essere puramente tecnica. Questo non è DDD. DDD parla di Ubiquitous Language e Bonded Context, non di DTO, servizi e repository.

score 0 · Answer 2

CQRS può avere senso ovunque. CQRS significa che si separano le letture e le scritture nel livello dell'applicazione, per renderle separate preoccupazioni, e il gioco è fatto. Entrambi i comandi e le query possono utilizzare lo stesso database, solo per CQRS non è necessario leggere da un database diverso da quello che si sta scrivendo. Puoi farlo, ma non è necessario.

È il sourcing di eventi, che va molto bene insieme a CQRS, che complica la roba, perché i tuoi aggregati non sono più oggetti ma una serie di eventi con cui sono costruiti. Una volta che avvii l'integrazione di event sourcing nel tuo sistema, potresti iniziare a pensare di utilizzare un archivio dati diverso (forse basato su documenti) per le letture per evitare la necessità necessaria di reidratare gli aggregati su ogni richiesta - ma anche in questo caso potrebbe non essere necessario affatto. Se si dispone di aggregati di eventi che possono raggiungere solo fino a 10 eventi, gestire un archivio dati separato è probabilmente inutile, poiché idratare 10 eventi nella memoria stessa è comunque molto rapido.