Gli oggetti immutabili e il DDD vanno insieme?

Il calcolo utilizzando oggetti immutabili (come nella programmazione funzionale) non implica necessariamente la persistenza di ogni oggetto generato!

Immutabile nel dominio significa che deve essere immutabile nel database? Ad esempio, considera il seguente presupposto che il cliente abbia sempre un indirizzo:

customer.address = new Address('My Castle', 'Kings street');
customer_repo.save(customer);

ora viene eseguito il seguente sql considerando che l'id cliente è 1:

INSERT INTO addresses (customer_id, name, street)
VALUES (1, 'My Castle', 'Kings street');

ora viene apportata la seguente modifica all'indirizzo:

customer.address = new Address('Pauper palace', 'Outlands');
customer_repo.save(customer);

e il livello di persistenza, essendo molto intelligente, esegue il seguente sql:

UPDATE addresses SET name='Pauper palance', street='Outlands'
WHERE customer_id = 1;

In questo modo si evita il sovraccarico di un'istruzione DELETE AND INSERT separata. Inoltre penso che alcuni RDBMS abbiano INSERT REPLACE o qualcosa del genere. MySql ha SOSTITUISCI .

In DDD, gli oggetti immutabili sono praticamente equivalenti agli oggetti valore. Questi oggetti non sono entità, non hanno un'identità. Pertanto, io continuo sempre a valutare gli oggetti come colonne dell'entità in cui sono contenuti (con N / Hibernate puoi usare i componenti per quello). Non hanno un proprio tavolo.

Dipende da come l'oggetto immutabile è mappato nel database. Se è solo un componente come un DateTime (dalla libreria Joda Time), la modifica del valore comporterà un aggiornamento piuttosto che un inserimento. Tuttavia, se l'immutabile è più complesso e richiede una riga in una tabella, allora hai il problema del bloat.

Suppongo che, sebbene sia un argomento debole, potresti implementare una pista di controllo in questo modo. Ogni modifica all'immutabile può essere tracciata attraverso gli inserti. Ci sono molti modi migliori per farlo però.

Tutto sommato l'avere oggetti di dominio immutabili (anziché solo i loro componenti) sembra un po 'una mancata corrispondenza con la persistenza.

Dipende dal dominio. DDD non specifica che il paradigma di programmazione sia orientato agli oggetti. Il paradigma object oriented è comunque adatto per l'applicazione tipica che deve essere persistente in un database.

DDD afferma semplicemente che è necessario creare il software attorno a un modello di dominio che rappresenta il problema reale che il software sta tentando di risolvere. Se quel problema fosse per esempio di natura matematica, implementare il livello del dominio usando la programmazione funzionale e le strutture di dati immutabili avrebbe molto senso.

Se d'altra parte, il problema è più tipico di un'applicazione aziendale e si utilizzano strutture di oggetti immutabili per tutti gli oggetti di dominio, quindi direi che non stai seguendo DDD. Posso inventare almeno due argomenti:

• La tua implementazione non rappresenta un modello di dominio del tuo dominio problematico. Il tuo dominio del problema in questo caso è costituito da entità che hanno lo stato da modificare. E non è così che l'hai implementato.

• Non hai una lingua ubiquitaria. La lingua e i concetti nel modello di dominio non seguono ciò che gli esperti di dominio stanno utilizzando.

Nota: DDD utilizza oggetti immutabili laddove appropriato, si chiamano semplicemente oggetti valore.

Quindi non sto dicendo che non è possibile creare un'applicazione di database utilizzando strutture di dati puramente funzionali, e non sto dicendo che non dovresti. Non penso che tu possa chiamarlo DDD, a seconda del tipo di applicazione

Se stai usando un ORM come Hibernate / NHibernate puoi impostare l'opzione cascade per eliminare automaticamente gli oggetti orfani. Se una persona ha un oggetto oggetto valore, quando cambi l'indirizzo, il nuovo sarà salvato e quello vecchio cancellato perché ora è orfano.

Gli oggetti valore sono quasi sempre immutabili in DDD e il modello di peso mosca può essere usato per mantenere in memoria la duplicazione dell'oggetto di quel valore, proprio come fa .NET con le stringhe. Il principale compromesso è la memoria su un lato e l'altro lato sull'efficienza creazionale. Con il modello del peso mosca, è necessario eseguire un confronto basato sul valore per determinare se un oggetto valore nuovo o ricostituito si trova già nella cache del peso mosca, ma qualsiasi altro confronto dopo tale punto può essere generalmente eseguito in modo sicuro mediante riferimento poiché viene applicata una singola istanza. In entrambi i casi, se il flyweight è usato o meno, gli oggetti valore sono ancora resi immutabili perché hanno solo un'identità intrinseca e cambiando così il loro valore cambierebbe la loro identità.

C'è un altro modo di usare oggetti immutabili ...

Invece di memorizzare valori 5.0, 6.0, 7.0, 8.0 e copiare l'intero record ogni volta, è possibile memorizzare qualcosa come: 5.0, +1.0, +1.0, +1.0, quindi creare correttamente le dipendenze per ricostruire la sequenza 5.0, 6.0, 7.0, 8.0. In questo modo piccole modifiche richiedono solo una piccola quantità di memoria ...