Mantenere un modello di dominio coerente con i dati reali

Question

Mantenere un modello di dominio coerente con i dati reali

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

5

Recentemente la progettazione basata sul dominio ha attirato la mia attenzione e, mentre pensavo a come questo approccio poteva aiutarci, ho trovato il seguente problema.

Nel DDD l'approccio comune è quello di recuperare entità (o meglio radici aggregate) da un repository che funge da raccolta in memoria di queste entità. Dopo che queste entità sono state recuperate, possono essere aggiornate o eliminate dall'utente, tuttavia dopo il recupero vengono sostanzialmente disconnesse dall'origine dati e si deve informare attivamente il repository per aggiornare l'origine dati e renderla coerente con la nostra in-memory rappresentazione.

Qual è l'approccio DDD al recupero di entità che dovrebbero rimanere connesse all'origine dati? Ad esempio, nella nostra situazione recuperiamo una serie di sensori che hanno una misurazione specifica durante il recupero. Nel tempo, questi valori di misurazione potrebbero cambiare e la nostra logica aziendale nel modello di dominio dovrebbe rispondere correttamente a questi cambiamenti. Ad esempio, gli eventi di dominio possono essere generati se un valore di sensore supera una soglia predefinita.

Tuttavia, utilizzando l'approccio del repository, questi valori del sensore sono solo istantanee e vengono disconnessi dall'origine dati. Qualcuno di voi ha un'idea su come risolvere questo problema seguendo l'approccio DDD?

domain-driven-design architecture

posta fstuijt 21.11.2012 - 14:11

fonte

2 risposte

Leggi altre domande sui tag domain-driven-design architecture

come strutturare i modelli MVC e i modelli ORM Come progettare un pattern composito in Python?

score 1 · Answer 1

Penso che sia necessario separare le aree di interesse in quanto sono davvero separate. Considerarli insieme non fa altro che confondere il quadro.

In primo luogo, hai la rappresentazione dei tuoi dati di monitoraggio / SCADA e gli aggiornamenti periodici che saranno necessari per questo.

In secondo luogo, hai la generazione di eventi basati sulle letture del sensore.

La maggior parte dei sistemi SCADA con cui ho lavorato ha qualche meccanismo per eseguire periodicamente il polling dell'origine dati per aggiornare il display. Avrai bisogno di un meccanismo simile per la tua applicazione. Ciò non viola il DDD, in quanto il focus di DDD è il modo in cui i dati sono mappati al dominio non in quanto spesso viene recuperato.

Generalmente, le letture dei sensori sono una cosa di sola lettura, ma potrebbero essere necessarie sovrascritture. Per consentire la sovrascrittura, è necessario tenere traccia dei timestamp associati ai valori modificati. Avrai bisogno di una funzione per sovrascriverla all'interno dell'archivio dati o, in alternativa, scrivere su un'altra tabella che ha l'accesso preferenziale al recupero dei valori originali. Di nuovo, questo non viola il DDD.

Per il secondo aspetto, avrai bisogno di un qualche tipo di agente di monitoraggio degli eventi. Seguire un approccio DDD dovrebbe aiutarti qui. L'allineamento dello schema dati con le strutture dell'applicazione e la logica aziendale semplificano l'aggiornamento delle regole in base alle esigenze. Sospetto che il tuo ambiente di oggetti di business sia ragionevolmente statico, quindi non dovrai preoccuparti di accettare i cambiamenti strutturali tutto questo spesso. Immagino che avrai delle modifiche alle soglie di allarme e / o nuove combinazioni di flussi di dati per l'analisi.

Risposta lunga breve - Il DDD non preclude nessuna delle preoccupazioni sollevate. Riguarda il modo in cui strutturi i tuoi dati.

score 1 · Answer 2

Per rispondere alla domanda, sarebbe utile conoscere il modello di coerenza appropriato per l'applicazione. Sarebbe sufficiente la consistenza finale ? In altre parole, in che modo "connesso" devono essere i dati? Inoltre, che tipo di tecnologia di archiviazione viene utilizzata? Un database relazionale? Un database NoSQL con indebolimenti ACID vincoli?

Uno dei problemi è che non appena i dati vengono letti dal database in memoria, esiste già un rischio di incoerenza, a meno che non venga emesso un blocco di scrittura. Tuttavia, nel tuo caso, non è possibile emettere un blocco di scrittura perché i dati devono essere aggiornati da un'altra fonte. Pertanto, devi abbracciare la coerenza finale perché ci sarà un ritardo tra il momento in cui i dati del sensore vengono aggiornati e quando tali informazioni raggiungono il codice del dominio.

Se la coerenza finale è accettabile, è possibile implementare un gestore messaggi che ascolta i dati del sensore e invoca il codice del livello dominio appropriato, che a sua volta può aumentare gli eventi del dominio. Questo gestore di messaggi è in un certo senso al di fuori del tuo livello di dominio: è un problema di livello infrastrutturale / applicativo. È molto simile a un gestore di messaggi in qualcosa come NServiceBus o MassTransit, con l'unica differenza che il meccanismo di archiviazione sottostante è diverso. (Anche se MSMQ o ZeroMQ sono adatti per l'applicazione, è sufficiente utilizzarli).