Nel mio progetto, ho un flusso di lavoro che opera su più entità per realizzare una transazione commerciale. Qual è il posto migliore per rappresentare la logica del flusso di lavoro? attualmente ho appena creato un "XXXManager" che è responsabile della collaborazione con gli oggetti entità per concludere una transazione commerciale. Ci sono altre opzioni?Domain Driven Design: dove si trova la logica del flusso di lavoro?
DDD potrebbe non essere esattamente di questo genere di cose, quindi suggerirei di dare un'occhiata al modello architettonico del livello di servizio. Il libro di Martin Fowler Patterns of Enterprise Architecture è un buon libro che lo spiegherà. Puoi anche trovare la descrizione del modello sul sito web di Fowler.
Creazione di sistemi di flusso di lavoro può essere una prospettiva scoraggiante. Hai preso in considerazione l'utilizzo di Workflow engines?
Se ho capito bene, sarà necessario creare un gestore che tenga traccia delle diverse transazioni nel flusso di lavoro, relative all'utente. Ci sono probabilmente altri modi per farlo - ma ho sempre usato i motori.
Di solito c'è un oggetto dominio che dovrebbe effettivamente gestire il controllo che viene scambiato per una "entità".
Esiste un'istanza di qualcosa che viene creato come risultato di questo flusso di lavoro? Se è così, la logica del flusso di lavoro probabilmente appartiene a questo. Considera "Ordine" nel modello qui sotto.
alt text http://img685.imageshack.us/img685/4383/order.png
Oder è sia un sostantivo e un verbo. "Ordine" è l'oggetto creato come risultato di "Ordine". Come ogni buona classe, ha sia dati che comportamenti (e non intendo getter e setter). Il comportamento è il processo dinamico associato ai dati, ad esempio il flusso di lavoro degli ordini. "Ordine" è il controller.
Ecco perché OO è stato inventato.
Direi che stai facendo la cosa giusta avendo qualcosa che collabora con più entità per fare qualcosa. La cosa importante è che ogni entità (e in effetti ogni servizio) dovrebbe avere un single responsibility.
Il flusso di lavoro generale di cui parli è qualcosa che puoi considerare come parte del tuo Livello applicazione.
According to Paul Gielens (parafrasato) La responsabilità del livello di applicazione è quella di digerire le richieste (messaggi/comandi) granulose per raggiungere un determinato obiettivo generale. Lo fa inviando un messaggio ai Servizi di dominio per l'adempimento. Quindi, anche (facoltativamente) decide di inviare notifiche al servizio di infrastruttura.
Ma che cos'è un "servizio" ?! Si tratta di un termine di sovraccarico, ma uno che è descritto bene (di nuovo, by Paul Gielens)
Si potrebbe anche voler leggere su Onion Architecture per altre idee ...
txn per il riferimento di Architettura di Onion, articolo interessante! –
Per le grandi risposte, vorrei aggiungere "domain events" (link è solo per una possibile implementazione) che è qualcosa su cui Evans stesso è venuto a mettere più attenzione ("increased emphasis on events").
Si potrebbe dire che la modellazione del dominio OO riguarda la denominazione dei verbi. –