none
struttura dominio fatturazione RRS feed

  • Domanda

  • ciao, volevo alcune dritte su come impostare il dominio per una fatturazione. da premettere che sto sviluppando un 

    applicazione con asp.net mvc 3. io avevo intenzione di crearmi un aggregato con tre entità testata, corpo e piede.Perche 

    quando salvo me la dovrebbe salvare nel db in tre tabelle diverse corrispondenti alle mie entitàCome potrei costruirlo il 

    mio domino? ci sono altre soluzioni migliori?
    Avevo pensato di creare qualcosa di simile(è la prima volta che provo a fare qualcosa del genere):

       public class Fattura:Aggregate
        {
        
          
    
            public virtual Testata Testata {get;set;}
    
            public virtual Corpo Corpo{get;set;}
    
            public virtual Piede Piede{get;set;}
    
        }
    
    
    public class Testata
    {
       public virtual int NumeroFattura{get:set;}
       public virtual Datetime DataFattura{get:set;}
       public virtual string Cliente{get:set;}
    }
    
    public class Corpo
    {
       public virtual string Articolo{get:set;}
       public virtual string Imballo{get:set;}
       public virtual double Prezzo{get:set;}
    }
    
    public class Piede
    {
       public virtual double Iva{get:set;}
       public virtual double  Imponibile{get:set;}
       public virtual double  Totale{get:set;}
    }



    potrebbe funzionare?
    lunedì 24 settembre 2012 15:30

Risposte

  • Ciao brux88,

    You wrote on 24/09/2012 :

    potrebbe funzionare?

    no :-) quello è un object model non un domain model, quindi non funziona :-P

    Suggerimento "talebano" per capire cosa vuol dire avere un domain model:
    - togli tutte le proprietà pubbliche;
    - metti solo field privati;
    - esponi solo metodi "void";

    Che cosa ti resta? un DomainModel che incapsula i dati ed espone solo comportamenti :-)

    A questo punto il modello che hai postato tu diventa un perfetto modello, magari uno dei tanti, anemico per fare le query sui dati e costruirci sopra le View(s)

    .m



    blog @ //milestone.topics.it
    • Proposto come risposta Irina Turcu martedì 9 ottobre 2012 16:56
    • Contrassegnato come risposta Irina Turcu venerdì 2 novembre 2012 14:08
    martedì 25 settembre 2012 06:58

Tutte le risposte

  • Ciao brux88,

    You wrote on 24/09/2012 :

    potrebbe funzionare?

    no :-) quello è un object model non un domain model, quindi non funziona :-P

    Suggerimento "talebano" per capire cosa vuol dire avere un domain model:
    - togli tutte le proprietà pubbliche;
    - metti solo field privati;
    - esponi solo metodi "void";

    Che cosa ti resta? un DomainModel che incapsula i dati ed espone solo comportamenti :-)

    A questo punto il modello che hai postato tu diventa un perfetto modello, magari uno dei tanti, anemico per fare le query sui dati e costruirci sopra le View(s)

    .m



    blog @ //milestone.topics.it
    • Proposto come risposta Irina Turcu martedì 9 ottobre 2012 16:56
    • Contrassegnato come risposta Irina Turcu venerdì 2 novembre 2012 14:08
    martedì 25 settembre 2012 06:58
  • ecco il mio problema sta proprio qui. capire cosa si intende per logica del domain. Perche per ora non sono altro che semplici campi get e set.

    come dovrei implementare questi metodi void? non riesco a capirne il vantaggio. se è possibile qualche esempio per poterne capire meglio la logica. Io ho visto un dominia che è una cosa simile ma non riesco a capirlo:

    	public class Articolo : Aggregate
    	{
    		protected internal Articolo()
    		{
    		}
    
    		public string Descrizione { get; private set; }
    
    		public double Prezzo { get; set; }
    
    		public UnitaMisura UnitaMisura { get; private set; }
    
    
    
    		public static Articolo Crea(string descrizione, double prezzo, UnitaMisura unitaMisura)
    		{
    			return
    				new Articolo { Descrizione = descrizione, Prezzo = prezzo, UnitaMisura = unitaMisura };
    		}
    

    martedì 25 settembre 2012 07:14
  • Ciao brux88,

    You wrote on 25/09/2012 :

    ecco il mio problema sta proprio qui. capire cosa si intende per logica del domain. Perche per ora non sono altro che semplici campi get e set.

    quindi non sono logica ma sono dati.

    come dovrei implementare questi metodi void? non riesco a capirne il vantaggio. se è possibile qualche esempio per poterne capire meglio la logica. Io ho visto un dominia che è una cosa simile ma non riesco a capirlo:

    facciamo un paio di esempi agli antipodi e un po' tirati per i capelli:

    - "Fattura" è un aggregato? tirandola un po' per i capelli no, non ha comportamento (non è proprio vero ma per ora prendilo per buono) una fattura una volta creata è scolpita nella pietra, fine non ci puoi fare più nulla, ergo una normalissima classe con proprietà in solo get basta e avanza per fare tutto quello che ti serve;

    - "Ordine" è ovviamente molto più interessante perché un ordine porta con se si dei dati ma ancor di più un sacco di comportamenti, ad esempio:
     * ContrassegnaComeSpedito;
     * Annulla;
     * StornaPezzi
     * ContrassegnaComeConsegnato;
     * è mattina presto ho finito le idee :-)

    Ora, alcuni di quei "metodi" probabilmente sarebbero fattibili anche con una singola proprietà (e.g. "bool Spedito") ma un aggregato per DDD è responsabile di garantire la consistenza delle sue informazioni (dati) ergo io utilizzatore dell'aggregato non devo assolutamente essere responsabile (e quindi sapere) che per mettere l'aggregato in un determinato stato devo fare una serie di operazioni, io da fuori devo solo sapere che chiamando quel metodo (comportamento) l'aggregato passa dallo stato attuale e quello nuovo e ci passa sicuramente oppure fallisce del tutto in maniera atomica senza che i dati restino corrotti.

    Il tuo obiettivo quindi in un dominio è modellare comportamenti non dati, quelli li possiamo tranquillamente ridurre ad un dettaglio tecnologico derivante e dipendente dalle scelte in termini di DBMS che hai fatto.

    .m



    blog @ //milestone.topics.it
    mercoledì 26 settembre 2012 04:55