Gli oggetti con logica di validazione nel loro dominio rappresentano davvero le loro controparti del mondo reale?

Il software non si preoccupa di rappresentare qualcosa. In definitiva, tutto è modificato e spostato la memoria.

Rappresentare un pezzo di carta nel software come un oggetto nel senso OO è perché è utile per noi umani capire sia ciò che il software effettivamente farà, contro ciò che il software dovrebbe fare, sia essere in grado di assicurati che quei due siano in armonia.

Quindi, tutte queste metodologie di sviluppo e design dei linguaggi di programmazione sono orientate a rendere il software comprensibile e gestibile per gli esseri umani.

Le cose dovrebbero essere mappate al mondo reale nella misura in cui il modello è conveniente. Per molti modelli, avere il modello stesso fa la propria convalida è più conveniente. Per gli altri, non lo è. Ma in nessun sviluppo ragionevole è quella decisione presa sulla base di ciò che un pezzo di carta fisico è in grado di.

C'è qualche convalida che può essere fatta solo con riferimento al dominio, anche se questo è un argomento secondo cui la validazione appartiene al dominio è moot.

La classificazione degli errori, e quindi la convalida, che ho familiarità con si divide in:

1. Errori di input, che possono essere rilevati esaminando l'input - quindi una data del 2014-02-30 è evidentemente sbagliata.
2. Errori di contesto, che possono essere rilevati solo esaminando l'oggetto dominio - quindi una data di nascita acquisita come 1990-01-31 e una data di inizio dell'istruzione del 1989-03-02 non è corretta. È questa classe di errori che può essere fatta solo con riferimento al dominio.
3. si trova nel sistema. Questi possono essere rilevati solo dalle informazioni contenute negli eventi successivi. Quindi se ti dico che la mia data di nascita è 1890-04-25 allora (nella peggiore delle ipotesi) potresti essere in grado di scoprire che questo non è corretto intorno all'anno 2010, quando ti dico che sono ancora vivo e vegeto. Questi errori possono essere corretti solo da azioni correttive che non rientrano nel sistema in questione. Queste azioni correttive possono essere molto estese o addirittura impossibili da implementare.

Now I'd like to address this question from a different angle: Shouldn't objects represent their real world counterparts?

Sì. Nella maggior parte delle aziende esiste già un sistema funzionante che dovrebbe essere tradotto nel software. O per dirla in altro modo, decenni di pratica aziendale hanno già probabilmente trovato un buon modo per gestire la maggior parte dei processi aziendali. E, cosa ancora più importante, quelli del settore comprendono già questi processi del "mondo reale", quindi quando si tratta di verificare se il tuo software fa quello che dovrebbe, puoi spiegare il tuo software in termini di processo del mondo reale che lo staff già familiare. Farlo in modo diverso nel software a come viene fatto nel mondo reale porterà a confusione e inefficienza.

So my question is this: if a physical piece of paper has no inherit ability to validate itself, then why would this behavior belong in the domain?

Guarda cosa succede nel mondo reale. La convalida viene gestita da un comportamento del broker, che esamina il foglio di carta e lo accetta o lo rifiuta in base ad alcune regole aziendali a cui è abituato.

Hai una "persona che convalida il modulo" oggetto nel mondo reale nella forma del ruolo che la persona sta giocando in quel momento. In alcune aziende che potrebbero essere lei stessa il broker, in altre organizzazioni più grandi potresti avere qualcuno che ha solo un lavoro e farlo.

In ogni caso è un'unità di comportamento unica, e come tale dovrebbe essere il suo oggetto che incapsula questo comportamento, indipendentemente dall'oggetto del modulo (il foglio)

Is the paper going to crumple itself up or catch on fire if you write something invalid on it?

No, ma un po 'di tempo in futuro, la carta può essere sostituita con una qualche forma di carta o pad elettronici, e ti si lamenteranno se fai un errore.

Il punto è che ci sono cose che sono possibili nel mondo virtuale che non sono possibili nel mondo reale degli atomi. Solo perché non esiste nel mondo reale non significa che non puoi o non dovresti modellarlo fittamente nel computer, se questa tecnica ti soddisfa, il tuo programma o le esigenze dei tuoi clienti.

Nel caso degli oggetti di input, non sarebbe bello se quegli oggetti fossero in grado di dirti "hey, I am invalid" senza che tu debba sapere nulla di loro?

Naturalmente, se stai costruendo qualcosa come una macchina per il voto o un selezionatore di una scuola che accetta forme con segni di matita o buchi, naturalmente il pezzo di carta non ti dirà che è successo qualcosa di brutto, la macchina . Ma prima che sia possibile, devi prima modellare quell'input cartaceo nel software della macchina, ed è quel modello che ti dirà che c'è un problema, non la carta.

Se il tuo oggetto è "Carta", allora per renderlo completamente riutilizzabile hai ragione - dovrebbe essere in grado di prendere qualsiasi contenuto senza scoppiare di fiamma (forse con alcuni controlli di base che si applicano sempre alla carta, come il colore di sfondo non può essere nero? Voglio dire come controlli null che mantengono valido l'oggetto cartaceo.)

Tuttavia viene quindi perfezionato in un "Form" (chiamiamolo oggetto Form1040 che estende o utilizza l'oggetto Paper), molti non hanno più controlli intrinseci ma verranno convalidati da qualche teller in una finestra, e se hai appena scarabocchiato casualmente, ma potrebbero accenderlo (anche se è più probabile che te lo restituiscano). Questo è probabilmente meglio rappresentato come un insieme di validazioni esterne all'oggetto "Form1040" a cui sono associate o associate (Pensa una serie di regole numerate scritte sul retro o in un opuscolo chiamato "Form1040 validations").

La cosa bella del set di validazioni è che puoi usarle per controllare il tuo modulo prima ancora di inviarlo allo sportello, quindi il cassiere può usare le stesse validazioni prima di accettarle e passarle a uno specialista di data entry, quindi il processo di immissione dei dati può finalmente applicare un ultimo controllo prima di rilasciarli nel database.

Cercare di costruire le convalide direttamente nell'oggetto sta seriamente limitando il riutilizzo e la manutenibilità. L'integrazione di un meccanismo di convalida specificato da metadati che funziona su più oggetti è un approccio davvero valido.

Il dominio ha anche un concetto di Servizi di dominio. Questo è ancora nel dominio, ma potrebbe rappresentare il processo del mondo reale che descrivi.

Un errore che possiamo fare è dimenticare che il dominio è qualcosa di più degli oggetti Entity: alcuni Servizi appartengono al dominio. Un modo per sbagliare è pensare che sia sbagliato passare un oggetto di servizio in altri oggetti di dominio, incluse le entità.

Un semplice esempio di come farlo correttamente è nel discorso di Jimmy Boogard su Vimeo intitolato "Crafting Wicked Domain Models". Passa un IOfferCalculator in un oggetto Entity Offer. Questa è la cosa giusta da fare, ma molti sviluppatori impazziscono quando vedono un oggetto che non proviene dall'ORM passato in uno che lo ha fatto, anche quando il riferimento è temporaneo.

Per quanto riguarda le regole di convalida, dipende in realtà dalle conseguenze comportamentali della convalida e / o dalla necessità o meno di applicare le stesse regole di convalida a più tipi.

Personalmente vedo una semplice convalida come un servizio di infrastruttura e cerco di utilizzare una libreria che svolge la maggior parte del lavoro per cose come i campi obbligatori o le lunghezze minime delle stringhe e così via.

Per la convalida che ha a che fare con lo stato di una singola Entità su più proprietà dove tale stato ha un significato specifico nel mio modello, esso appartiene assolutamente all'entità.

Che si tratti di raccolta di dati cartacei o di convalida di dati elettronici altamente convalidati, possono emergere discrepanze tra il modo in cui si pensa che le cose siano fatte da alcuni (gestione) e come viene fatto realmente sul campo.

Potresti sviluppare un diverso set di regole di dominio a seconda di come vengono raccolti i requisiti.

1. Modello basato sul modulo. Un supervisore ti consegna una copia vuota di un modulo cartaceo e ti istruisce a "fare esattamente come questo". Le istruzioni indicano "seleziona solo uno" in modo da codificarlo di conseguenza.
2. Modello basato sull'utilizzo. Il responsabile della revisione e del raggruppamento dei dati ti offre una serie di moduli completati. Si noti che alcune date sono state inserite come mese / anno perché nessuno ricorda il giorno esatto e non gliene importa. Selezionano più di un articolo nell'area riservata perché tutti hanno stabilito che una coppia di valori è più accurata (quanto tempo occorrerebbe per ottenere quel feedback in un sistema limitato?). Le persone fanno commenti sul retro e inseriscono altre note ai margini.

Uno sviluppatore potrebbe trovarsi in entrambi gli scenari e costruire ciò che il cliente "voleva", ma potresti scoprire che non hai costruito ciò di cui avevano bisogno. Il supervisore potrebbe aver riconosciuto le date inesatte e vuole forzarne uno più preciso (è per questo che ti abbiamo assunto) o vede i commenti e decide di aggiungerlo anche se non è presente nel modulo. Raramente starai bene la prima volta. Gli utenti cambieranno le regole (e negli affari non sono sempre logici).

Potresti trovarti a creare un ibrido di due modelli del mondo reale perché è possibile nel computer. Il modello del mondo reale tende a diventare così complesso, nessuno può dirti di cosa si tratta; è meglio affrontarne piccole parti alla volta, essere molto rigido all'inizio ma capire che potresti dover sciogliere le cose e prepararti a un sacco di cambiamenti.

I modelli di business (o qualsiasi altra persona che coinvolge le persone) e la percezione / interpretazione del modello e del dominio si evolvono costantemente, quindi probabilmente non c'è mai un punto in cui siano realmente corrispondenti.

Affrontare alcune applicazioni intranet di tipo "Gestisci progetto dall'inizio alla fine", credo che possa essere molto utile per acquisire separatamente quali diversi sistemi remoti o utenti hanno detto al mio sistema loro il pensiero era vero, rispetto al mix di dati che il mio sistema ha attualmente deciso di credere e onorare.

Questo porta a sistemi in cui si memorizzano e si agiscono su cose come "submission" (in sospeso, riuscito, non riuscito, archiviato) o "eventi" (AddressChangeRequested), piuttosto che CRUD-ish modifica take-it-or-leave-it .

Mentre aggiunge uno strato di astrazione, rende anche più facile gestire le cose strane che l'azienda insiste a mantenere, come consentire alcune contraddizioni, o applicare alcune modifiche "retroattivamente" da un punto successivo nel ciclo di vita delle attività.