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

Re: [DDD-IT] Re: Show me your code...provocazione.

Espandi messaggi
  • Uberto Barbini
    Buon anno a tutti. questa discussione sta diventando sempre piu interessante. ... Allora qui ci siamo chiariti, siamo in disaccordo (che ci sta benissimo). :)
    Messaggio 1 di 39 , 1 gen 2012
    Visualizza origine
    • 0 Allegato
      Buon anno a tutti.

      questa discussione sta diventando sempre piu' interessante.

      > Ecco, su questo siamo in pacifico disaccordo. :-D
      >
      > Per me, se dal suo punto di vista sono diverse, il computer riporta
      > banalmente questa differenza.

      Allora qui ci siamo chiariti, siamo in disaccordo (che ci sta benissimo). :)

      Vedi per me il punto di vista del computer e' diverso da quello
      dell'esperto, quindi a volte servono termini nuovi.

      > Conosco la differenza fra flussi e stock, ma a dire il vero ricordo che mi
      > hanno proprio spiegato che la partita doppia tratta i flussi da cui è
      > possibile determinare gli stock ad una qualsiasi data.
      > E mi hanno anche detto quella bagianata dei segni... Magari pensavano che in
      > quanto informatico, non potessi proprio capire! :-D

      :)
      wikipedia http://it.wikipedia.org/wiki/Partita_doppia
      lo chiama "principio della duplice rilevazione simultanea"
      se fai partita tripla avrai una triplice rilevazione simultanea ecc.
      se invece volessi usare una logica completamente enne a enne, potresti
      anche avere un numero illimitato di dimensioni. Una specie di tag
      cloud in cui ogni tag e' una partita.
      Questo e' stato un esperimento che ho fatto ma apparentemente non
      interessa a nessuno :(
      >> Per dire nel mio dominio attuale, spesso gli esperti parlano di
      >> "device" intendendo un telefono mobile. Pero' il termine device per
      >> gli esperti di marketing e' abbastanza ampio (il nome commerciale del
      >> cellulare) mentre per chi lavora nel campo di vendita di applicazioni
      >> ad ogni "device" deve corrispondere un certo firmware e una certa
      >> versione hw (alcuni giochi vanno solo su alcune versioni). Quindi i
      >> due gruppi usano device con significati leggermente differenti, che
      >> non sono un problema quando si parlano tra di loro, ma sono un
      >> problema per noi quando dobbiamo fare un sw che funzioni per entrambi.
      >
      >
      > In questo tipo di situazione, noi definiamo due bounded context, uno per il
      > marketing e uno per gli sviluppatori (o anche 3, se utilizziamo uno shared
      > kernel).
      > In ciascuno esisterebbe il concetto di device, ma con proprietà, comandi e
      > query specifiche per il contesto, ma esisterebbe un meccanismo di context
      > mapping (il più semplice dei quali è lo shared identifier).
      >
      > Non c'è bisogno di avere una visione del device che vada bene a tutti.

      No qui non ti seguo proprio.
      L'applicazione a cui sto pensando mostra sul cellulare del cliente
      delle promozioni tipo "clicca qui per avere angry birds al 50% di
      sconto", "nuovo piano superconveniente per le nipotine di Mubarak"
      ecc.
      Ora per ogni "device" il marketing crea un set di promozioni
      differente. E qui device==modello + costruttore (HTC Legend, Samsung
      Galaxy ecc.)
      Quando l'utente schiaccia su angrybirds, noi dobbiamo trovare la
      versione del gioco da scaricargli per quella "device". E qui device ==
      modello + costruttore + firmware versione + os version + localization.

      L'idea di avere due classi Device che sottintendano due cose diverse
      in due punti diversi del codice non mi piace per nulla. Noi abbiamo
      rinominato la seconda e insegnato anche ai Business Analyst ad usare
      un nome diverso.
      Nota che e' vero che la logica del download e' in un Bounded Context
      diverso, ma comunque il BC delle promozioni deve parlarci col BC dei
      download.
      Inoltre i documenti tecnici come l'High Level Design coprono tutto il
      ciclo, e' quindi importante si usino termini univoci.

      > Credo che l'unico vero difetto del libro blu sia non dare sufficiente peso
      > ai bounded context.

      A me pare che nella seconda parte ne parli abbastanza, mi pare un
      topic comunque molto avanzato e per progetti grossi... o forse sono io
      che dovrei usarli di piu. :)


      > Beh io posso dire che se applicato male è estremamente costoso.

      :)

      > IMHO, è costoso comunque, anche se applicato bene, ma è il costo minimo per
      > certi tipi di applicazioni (ovviamente se devono funzionare, se devono
      > macinare utili attraverso i bugfix e il body rental, no).

      Esatto e' quello che volevo dire io. Se vuoi un'applicazione di un
      certo tipo, che ti mappi un dominio esistente e complesso, e la vuoi
      che funzioni, allora DDD e' il metodo piu' economico che conosco.

      > Al contrario, se pubblicassimo solo i BC "migliori", sarebbe evidente che è
      > DDD (visti i VISION.txt, la documentazione delle interfacce, la forma delle
      > stesse etc...) a chiunque conosca C#.

      Quello che volevo dire e' "guardando il mio codice chiunque puo' dire
      che ho modellato il dominio, ma non puoi sapere se l'ho modellato
      giusto se non conosci il dominio stesso." Soprattutto da un punto di
      vista didattico, vedendo il codice senza la storia di come ci si e'
      arrivati, dubito che uno possa capire DDD.

      Pero' da autodidatta DDD, non so a cosa tu ti riferisca con "i
      VISION.txt, la documentazione delle interfacce, la forma delle stesse
      etc...."
      Immagino siano delle pratiche C#-DDD ma non credo proprio sia quello
      il punto di "riconoscere DDD".
      In generale non credo che il codice di DDD debba essere diverso da
      ottimo codice OOP.
      Non vorrei mai essere nella posizione di dovermi porre la domanda "ma
      questa cosa la faccio in OOP o in DDD?"

      > Beh, Epic lo è, ma in effetti non è un domain model è un framework per
      > sviluppare applicazioni DDD.

      Non conosco Epic, ma personalmente dubito forte che uno possa capire
      DDD guardando il codice di un framework, per quanto scritto bene.


      ciao

      Uberto
    • Alberto Brandolini
      Il giorno 01 gennaio 2012 12:28, Uberto Barbini ha ... A me interessa. Dal mio punto di vista non è altro che una variazione sul tema di
      Messaggio 39 di 39 , 1 gen 2012
      Visualizza origine
      • 0 Allegato
        Il giorno 01 gennaio 2012 12:28, Uberto Barbini <uberto@...> ha scritto:
         

        Buon anno a tutti.

        questa discussione sta diventando sempre piu' interessante.

        > Ecco, su questo siamo in pacifico disaccordo. :-D
        >
        > Per me, se dal suo punto di vista sono diverse, il computer riporta
        > banalmente questa differenza.

        Allora qui ci siamo chiariti, siamo in disaccordo (che ci sta benissimo). :)

        Vedi per me il punto di vista del computer e' diverso da quello
        dell'esperto, quindi a volte servono termini nuovi.

        > Conosco la differenza fra flussi e stock, ma a dire il vero ricordo che mi
        > hanno proprio spiegato che la partita doppia tratta i flussi da cui è
        > possibile determinare gli stock ad una qualsiasi data.
        > E mi hanno anche detto quella bagianata dei segni... Magari pensavano che in
        > quanto informatico, non potessi proprio capire! :-D

        :)
        wikipedia http://it.wikipedia.org/wiki/Partita_doppia
        lo chiama "principio della duplice rilevazione simultanea"
        se fai partita tripla avrai una triplice rilevazione simultanea ecc.
        se invece volessi usare una logica completamente enne a enne, potresti
        anche avere un numero illimitato di dimensioni. Una specie di tag
        cloud in cui ogni tag e' una partita.
        Questo e' stato un esperimento che ho fatto ma apparentemente non
        interessa a nessuno :(

        A me interessa.
        Dal mio punto di vista non è altro che una variazione sul tema di MVC.
        Però non è un argomento che puoi potare al tavolo con l'esperto di dominio, così a cuor leggero. 
        Rischi di portarlo fuori dall'area in cui si sente tranquillo.
         

        >> Per dire nel mio dominio attuale, spesso gli esperti parlano di
        >> "device" intendendo un telefono mobile. Pero' il termine device per
        >> gli esperti di marketing e' abbastanza ampio (il nome commerciale del
        >> cellulare) mentre per chi lavora nel campo di vendita di applicazioni
        >> ad ogni "device" deve corrispondere un certo firmware e una certa
        >> versione hw (alcuni giochi vanno solo su alcune versioni). Quindi i
        >> due gruppi usano device con significati leggermente differenti, che
        >> non sono un problema quando si parlano tra di loro, ma sono un
        >> problema per noi quando dobbiamo fare un sw che funzioni per entrambi.
        >
        >
        > In questo tipo di situazione, noi definiamo due bounded context, uno per il
        > marketing e uno per gli sviluppatori (o anche 3, se utilizziamo uno shared
        > kernel).
        > In ciascuno esisterebbe il concetto di device, ma con proprietà, comandi e
        > query specifiche per il contesto, ma esisterebbe un meccanismo di context
        > mapping (il più semplice dei quali è lo shared identifier).
        >
        > Non c'è bisogno di avere una visione del device che vada bene a tutti.
         

        No qui non ti seguo proprio.
        L'applicazione a cui sto pensando mostra sul cellulare del cliente
        delle promozioni tipo "clicca qui per avere angry birds al 50% di
        sconto", "nuovo piano superconveniente per le nipotine di Mubarak"
        ecc.
        Ora per ogni "device" il marketing crea un set di promozioni
        differente. E qui device==modello + costruttore (HTC Legend, Samsung
        Galaxy ecc.)
        Quando l'utente schiaccia su angrybirds, noi dobbiamo trovare la
        versione del gioco da scaricargli per quella "device". E qui device ==
        modello + costruttore + firmware versione + os version + localization.

        L'idea di avere due classi Device che sottintendano due cose diverse
        in due punti diversi del codice non mi piace per nulla.

        Se sono in due Bounded Context diversi non è un problema.
        Se sono nello stesso BC allora si deve agire a livello di naming. Il punto è che il Bounded Context si "leggono" più spesso di quanto non si "scrivano". Quindi se le cose sono state sviluppate da team diversi con una diversa idea di Device, hai 2 BC de-facto. Se uno stesso gruppo o gruppo allargato decide di lavorare per rimuovere le ambiguità tra più BC, di fatto ne sta facendo uno più grande, facendo un lavoro certosino di rinomina.

        Tutto legittimo. Dipende dal rapporto costi benefici specifico della situazione.

        Noi abbiamo
        rinominato la seconda e insegnato anche ai Business Analyst ad usare
        un nome diverso.
        Nota che e' vero che la logica del download e' in un Bounded Context
        diverso, ma comunque il BC delle promozioni deve parlarci col BC dei
        download.

        Qui in DDD hai N scelte: Conformist, Anti-Corruption Layer, Partner, il punto è qual è la modalità di collaborazione che hai per poter condividere un modello. In questo caso credo di poter dire che abbiate adottato uno shared kernel, o che comunque siate su partnership o customer-supplier in ogni caso, configurazioni ad alto passaggio di informazioni.
         
        Inoltre i documenti tecnici come l'High Level Design coprono tutto il
        ciclo, e' quindi importante si usino termini univoci.

        Questo è un'aspetto interessante. Ma è anche vero che i contesti possono/devono essere pubblici noti, specialmente a questo livello.
         

        > Credo che l'unico vero difetto del libro blu sia non dare sufficiente peso
        > ai bounded context.

        A me pare che nella seconda parte ne parli abbastanza, mi pare un
        topic comunque molto avanzato e per progetti grossi... o forse sono io
        che dovrei usarli di piu. :)
         
        Credo sia questa l'impressione sbagliata che viene fuori dal libro. Io ora parto dalla lettura dei BC e dal presidio del confine del mio BC, altrimenti non posso modellare correttamente. Specialmente in presenza di qualcosa di già esistente. Se parto dal foglio bianco, ci sta che stia tutto o quasi in un BC e che gli altri modelli siano talmente chiaramente esterni da non rappresentare un problema.
         

        > Beh io posso dire che se applicato male è estremamente costoso.

        :)

        > IMHO, è costoso comunque, anche se applicato bene, ma è il costo minimo per
        > certi tipi di applicazioni (ovviamente se devono funzionare, se devono
        > macinare utili attraverso i bugfix e il body rental, no).

        Esatto e' quello che volevo dire io. Se vuoi un'applicazione di un
        certo tipo, che ti mappi un dominio esistente e complesso, e la vuoi
        che funzioni, allora DDD e' il metodo piu' economico che conosco.

        > Al contrario, se pubblicassimo solo i BC "migliori", sarebbe evidente che è
        > DDD (visti i VISION.txt, la documentazione delle interfacce, la forma delle
        > stesse etc...) a chiunque conosca C#.

        Quello che volevo dire e' "guardando il mio codice chiunque puo' dire
        che ho modellato il dominio, ma non puoi sapere se l'ho modellato
        giusto se non conosci il dominio stesso." Soprattutto da un punto di
        vista didattico, vedendo il codice senza la storia di come ci si e'
        arrivati, dubito che uno possa capire DDD.

        Pero' da autodidatta DDD, non so a cosa tu ti riferisca con "i
        VISION.txt, la documentazione delle interfacce, la forma delle stesse
        etc...."
        Immagino siano delle pratiche C#-DDD ma non credo proprio sia quello
        il punto di "riconoscere DDD".
        In generale non credo che il codice di DDD debba essere diverso da
        ottimo codice OOP.

        Sottoscrivo, DDD si preoccupa forse un po' di più di trovare il posto corretto per poterlo fare :-) ma è anche vero che alcune cose di OOP non è detto che trovino la loro applicazione a livello di domain model. Modellare il dominio è comunque una specializzazione della classe di problemi risolvibili con OOP.
         
        Non vorrei mai essere nella posizione di dovermi porre la domanda "ma
        questa cosa la faccio in OOP o in DDD?"

        > Beh, Epic lo è, ma in effetti non è un domain model è un framework per
        > sviluppare applicazioni DDD.

        Non conosco Epic, ma personalmente dubito forte che uno possa capire
        DDD guardando il codice di un framework, per quanto scritto bene.

        Sottoscrivo, molto più importante il come ed il perché ci arrivi.

        Ciao (e buon anno)!

        Brando

      Il tuo messaggio è stato inviato correttamente e verrà recapitato a breve ai destinatari.