Caricamento ...
Spiacenti, si è verificato un errore durante il caricamento del contenuto.

DDD and relational databases – the value object dilemma

Espandi messaggi
  • ruggeri.alex
    Volevo segnalarvi questo interessante post di Gojko Adzic: http://gojko.net/2009/09/30/ddd-and-relational-databases-the-value-object-dilemma/ Dopo averlo
    Messaggio 1 di 3 , 2 ott 2009
    Visualizza origine
    • 0 Allegato
      Volevo segnalarvi questo interessante post di Gojko Adzic:
      http://gojko.net/2009/09/30/ddd-and-relational-databases-the-value-object-dilemma/

      Dopo averlo letto, il dilemma rimane intatto...
      Se ho bisogno di fare ricerche (query) sui singoli attributi di un value object (95% dei casi) quale dei 3 metodi scegliereste?

      Alex Ruggeri
    • Alberto Brandolini
      Ciao Alex, Grazie per la segnalazione del post. Gojko ha affrontato l argomento in aula all ultimo corso di DDD che abbiamo fatto insieme a giugno, quindi
      Messaggio 2 di 3 , 2 ott 2009
      Visualizza origine
      • 0 Allegato
        Ciao Alex,

        Grazie per la segnalazione del post.
        Gojko ha affrontato l'argomento "in aula" all'ultimo corso di DDD che abbiamo fatto insieme a giugno, quindi forse ho in testa qualche dettaglio in più.

        La risposta è nelle righe finali: la scelta della strategia migliore dipende dal contesto. Ma mi preme fare notare un'altra cosa che dall'articolo non emerge. In un contesto in cui hai correttamente partizionato il tuo domain model in aggregati ed in cui to trovi ad operare in un bounded context in cui il tuo value object è usato in un modo chiaro e trasarente, la risposta diventa: "prova".

        L'impostazione DDD di fondo di permette di sperimentare la strategia di persistenza che preferisci sul VO. Per la quale potresti avere anche considerazioni domain-specific (ad esempio la rappresentazione a stringhe HKG-SEA-DAL) può permettere ad un utente "smart" di fare in maniera ultra semplice una query del genere "tutti gli itinerari che passano per la tratta Seattle-Dallas"), minimizzando i "ripple effect" delle sperimentazioni, permettendoti quidi di trovare l'implementazione "giusta" per il tuo contesto.

        Brando


        Il giorno 02 ottobre 2009 10.12, ruggeri.alex <alexr@...> ha scritto:
         

        Volevo segnalarvi questo interessante post di Gojko Adzic:
        http://gojko.net/2009/09/30/ddd-and-relational-databases-the-value-object-dilemma/

        Dopo averlo letto, il dilemma rimane intatto...
        Se ho bisogno di fare ricerche (query) sui singoli attributi di un value object (95% dei casi) quale dei 3 metodi scegliereste?

        Alex Ruggeri




        --
        Alberto Brandolini
        Phone: +39-347-6005027
        E-mail: alberto.brandolini@...
        Web page; http://albertobrandolini.wikidot.com
        Blog: http://ziobrando.blogspot.com
        Linkedin page: http://www.linkedin.com/in/brando
      • Jacopo Romei
        Interessantissimo. Anche solo per riconoscersi in problematiche e *soluzioni*, che è sempre un bel massaggio per il consulente a piedi solo nella giungla dei
        Messaggio 3 di 3 , 2 ott 2009
        Visualizza origine
        • 0 Allegato
          Interessantissimo. Anche solo per riconoscersi in problematiche e *soluzioni*, che è sempre un bel massaggio per il consulente a piedi solo nella giungla dei "domain" altrui ;)

          La gerarchia di oggetti serializzata in un clob/blob compare anche fra i pattern Fowleriani. L'ho usata con successo molte volte.
          Ho avuto esperienze anche con la chiave primaria 'debole' del primo approccio. Per esempio quando, per facilitare la vita ad un generatore di applicazioni di backend che mi piace molto, permetto a 'lui' di usare una chiave primaria, nel layer che in DDD definiremmo 'infrastrutturale', mentre nel layer di dominio la stessa chiave non aveva alcun senso, anzi, non esisteva affatto.

          --
          Jacopo Romei
          http://www.sviluppoagile.it/
        Il tuo messaggio è stato inviato correttamente e verrà recapitato a breve ai destinatari.