Qual è il costo aziendale del modello di dominio anemico

Non credo che ciò che stai chiedendo sia effettivamente possibile. Il motivo per cui lo dico è semplicemente perché ti stai chiedendo se sia possibile giustificare un particolare design rispetto ad un altro quando ci sono troppe variabili che lo influenzano.

In primo luogo il dibattito sul modello di dominio anemico non è finalizzato. Ho sentito argomentazioni da entrambe le parti sul fatto che sia buono o cattivo. Penso che la realtà sia che "buono" e "cattivo" dipendono completamente dalle tecnologie che si stanno impiegando e dall'applicazione che si sta sviluppando. Se provi a escluderli, ci sono troppi "Sì - Ma" per avere una risposta.

La seconda considerazione è che quando si confrontano lo sviluppo di un prodotto usando X vs Y ci sono una serie di fattori che possono rovinare qualsiasi numero si provi a inventare. Soprattutto perché l'idea di poter confrontare il progetto A con il progetto B e dedurre un risultato di confronto su un fattore è come paragonare Boeing ad Airbus e dire che Arbus è migliore perché usano bulloni in titanio dove Boeing utilizza Hi Tensile Steel. Non so se lo fanno, ma tu hai l'idea.

I fattori che metteranno dei punti interrogativi sui tuoi valori sono cose come le abilità dei membri del team, le filosofie progettuali, l'esperienza e le preferenze personali e le abitudini di codifica. Gli obiettivi del progetto, le tecnologie, le scadenze, i clienti e qualsiasi storia precedente. Supporto gestionale, finanziamento, influenza e controllo. Nessuno di questi due progetti sarà esattamente uguale in nessuno di questi fattori e quindi qualsiasi risultato "quantificabile" è al massimo discutibile quando si tratta di "questo" o "quello".

Diverse persone altamente competenti nel settore hanno utilizzato statistiche da un gran numero di progetti per fare varie generalizzazioni sullo sviluppo del progetto. Queste persone sono molto intelligenti e con esperienza. Se guardi parte del materiale di base sul dibattito tra cascata e agile, vedrai alcuni di questi dati. Penso che la tua richiesta sia lontana dalla macro per essere in grado di fare affermazioni simili "fattuali". A causa delle complessità coinvolte, puoi lavorare su larga scala solo con questo tipo di cose.

Con un modello di dominio anemico, il test diventa più costoso, perché la logica tende ad essere più unita alla persistenza. Un grande vantaggio per il modello del modello di dominio è la possibilità di testare le funzionalità chiave in modo Unit Test. Più veloce ed economico.

Come risultato di un approccio anemico, alcune squadre spendono (o sprecano) un sacco di tempo nel test. Il test deve includere le pulizie e garantire l'idempotenza. Sono più costosi e di solito non forniscono lo stesso grado di sicurezza che una suite di test dovrebbe fornire. Altre squadre, prova di meno. Il test non sembra così accattivante a causa del grande investimento in termini di tempo e quindi ... sfiducia . Entrambi gli approcci portano a costi maggiori quando si tratta di ulteriori evoluzioni.

La fiducia potrebbe non sembrare un termine allettante per la gestione, ma influenza gravemente la capacità di un reparto IT di rispondere (o anticipare ) alle esigenze aziendali in evoluzione.

Tuttavia, non tutte le parti del software hanno le stesse aspettative per il futuro. Alcuni componenti potrebbero rispondere a un bisogno temporaneo e nessuna evoluzione è all'orizzonte. Alcuni altri potrebbero aver bisogno di un'evoluzione continua a causa di molti fattori.

• Requisiti aziendali in evoluzione.
• Dipendenze con strumenti e librerie esterne.
• Apprendimento continuo del dominio.
• Regole che cambiano frequentemente.

Per il software la cui aspettativa di vita è di includere molta manutenzione / evoluzione, è inutile concentrarsi sull'ottimizzazione del tempo di scrittura (che è l'approccio di marketing più attraente per la maggior parte dei framework, comunque). Per software la cui aspettativa è diversa, più strategie a breve termine potrebbero essere ragionevoli. Chiaramente, possiamo sbagliato . : -)

È difficile da fare, ma può essere fatto se hai mantenuto le metriche relative al tuo processo di sviluppo. Avrai anche bisogno di un confronto per basare i tuoi presunti costi contro. Idealmente, si avrebbe un team / progetto identico senza un modello di dominio anemico da confrontare. Ovviamente, non è realistico quindi un progetto one-off creato dallo stesso team ma senza il trascinamento del modello di dominio sarebbe sufficiente.

Da lì, devi semplicemente confrontare il tasso di sviluppo tra i due progetti. Le righe di codice scritte sono un metodo, ma non penso che sia molto significativo. Richieste di funzionalità simili sarebbero un confronto migliore, secondo me. E vorrete misurare la quantità di tempo sia in calendario che in tempo per lo sviluppatore necessaria per fornire le funzionalità. Se le tue metriche ti consentono di approfondire la ricerca dei requisiti e il controllo qualità, tali aspetti dello SDLC possono presentare informazioni utili e supplementari.

In un caso ideale, avrai i requisiti - > dev - > test / QA misurati. Un confronto perfetto delle funzionalità avrebbe tempi simili per requisiti e test, ma una maggiore quantità di tempo di sviluppo. Dal momento che hai controllato in modo efficace altri fattori probabili (team diversi, ...) puoi quindi puntare al modello di dominio anemico come colpevole per il maggiore tempo di sviluppo.

La traduzione del tempo di sviluppo aumentato in denaro è altrettanto "facile". Ci sono due fattori principali da considerare qui - in primo luogo i dollari di sviluppo grezzo basati sulla percentuale interna di spese generali * di aumento nel tempo. Il secondo è il costo opportunità. Aumenta le entrate annuali del tuo prodotto e dividi il tempo del tuo sviluppatore. Ciò fornirà una misura un po 'approssimativa ma valida delle potenziali entrate perse una volta moltiplicato il costo dell'opportunità orario rispetto all'aumento del tempo di sviluppo.

Hai menzionato anche i costi di supporto. Un approccio simile per documentare il tempo trascorso sul prodotto ABC rispetto a XYZ con le chiamate di supporto fornirà le basi della tua analisi.

Realisticamente parlando, avrai difficoltà a trovare numeri ideali come quello. Se non hai alcuna metrica, non sono sicuro che riuscirai a fare un caso. Documenta le tue ipotesi, raffina un po 'i numeri per renderli più gestibili e conduci la tua valutazione da parte di un confidente fidato all'interno dell'azienda per assicurarti che il messaggio sia chiaro.

Di solito i modelli di dati anemici vengono forniti da utenti pubblici. Quindi hai qualcosa di simile:

public class Order
{
    public string Id { get; set; }
    public string UserId { get; set; }
    public OrderState State { get; set; }
    public DateTime StateChangedAt { get; set; }
    public List<OrderLine> Products { get; set; }
}

Diciamo che hai una routine che analizzerà tutti gli ordini che segnaleranno che gli ordini sono stati in stato di WaitingOnStock per due settimane. Quindi, in un punto in cui è impostato lo stato, hai

var order = _repository.Get(orderId);
if (product.StockCount == 0)
{
    order.Products.Add(new OrderLine(4, product));
    order.State == OrderState.WaitingOnStock;
}
_repository.Save();

Vedi? Poiché lo sviluppatore non sa / ha dimenticato il campo StateChangedAt , la routine di notifica non funzionerà.

Se invece hai lasciato che il controllo della classe Order fosse un comportamento che non sarebbe successo:

public class Order
{
    public string Id { get; private set; }
    public string UserId { get; private set; }
    public OrderState State { get; private set; }
    public DateTime StateChangedAt { get; private set; }
    public IEnumerable<IOrderLine> Products { get; private set; }

    public void Add(int quantity, Product product)
    {
        Products.Add(new OrderLine(quantity, product);

        if (product.Quantity < quantity)
        {
            StateChangedAt = DateTime.Now; 
            State = OrderState.WaitingOnStock;
        }
    }
}

Quindi ciò che fai in pratica è seguire il principio OOP fondamentale incapsulamento . Come bonus, ottieni tutte le logiche di business relative all'ordine in un unico posto che semplifica enormemente qualsiasi bug tracking.

Ne ho anche parlato in modo blogger: link

Non penso che ci sarà uno studio peer reviewed su cui puoi fare affidamento o un semplice modello empirico da cui attingere; anche nella misura in cui una cosa del genere potrebbe esistere, provare che i dati si adattano alla tua situazione potrebbe essere piuttosto difficile. Il fatto che tale adattamento del modello sia così poco pratico è la ragione per cui il business tende a fare molto affidamento sul "case study" di rilevamento di ciò che di solito è una singola azienda o squadra che cambia pratica da x a y (o fornitore da a a b). L'errore narrativo è spesso al lavoro, ma è uno dei pochi strumenti che hanno un qualche tipo di trazione al di fuori del neo-taylorismo pseudoscientifico, perché le persone hanno un'incredibile abilità di abbinamento dei modelli e hanno un'intuizione (giustificata o meno da altri dati) se un caso di studio ha qualche lezione trasferibile alla loro situazione. Penso che questo tipo di dipendenza da uno studio di caso possa essere frustrato dal punto di vista intellettuale come lo era la "gestione scientifica", ma ciò non impedirà alle persone di utilizzarli.

La cosa da misurare è davvero l'attrito dello sviluppo. Non sarai in grado di prevedere esattamente in che modo un modello di dominio strong possa influire sulla velocità, ma se inizi con un modello di dominio anemico e inizi a incoraggiare lo spostamento di più logiche di business dai livelli di servizio nel livello di dominio e incoraggi il frequente refactoring man mano che ottieni un una migliore comprensione del dominio, puoi almeno fare un paragone tra velocità (se stai usando qualcosa come story point per misurare approssimativamente la complessità del compito), o la soddisfazione del cliente, o la fragilità del sistema, o copertura del test, o qualsiasi cosa risuoni con il tuo organizzazione.

In base alla mia esperienza, immagino che troverai alcuni ostacoli iniziali quando inizierai a cambiare pratiche, poiché probabilmente dovrai affrontare alcuni sgradevoli effetti collaterali e il debito tecnico esistente, ma avrai un payoff a lungo termine se si effettuano investimenti progressivi in un vero dominio.

Se stai cercando di risolvere il caso in cui devi allontanarti da un modello di dominio anemico, la cosa migliore da fare è fornire dati su ciò che è difficile da cambiare ora, quali richieste dei clienti impiegano più tempo del dovuto perché hai per cambiare il codice in quattro posti diversi invece di uno, per esempio. Come spesso sostengo, il miglior caso di cambiamento è l'identificazione dei punti dolenti del sistema esistente; codice di lavoro inizierà a vincere qualsiasi argomento sul fatto che tu sia sulla strada giusta. Piuttosto che concentrarti sull'erogazione delle stime dei costi, concentrati su uno scenario ristretto a cui devi fornire valore commerciale a breve termine e inizia ad attaccare il problema rafforzando il modello di dominio.

Per essere case-study-ish senza nominare aziende specifiche in cui ho affrontato questo problema, ecco alcuni problemi con i progetti su cui ho lavorato con modelli di dominio anemici:

• Logica aziendale duplicata o leggermente divergente in più livelli del sistema, non applicata a livello di dominio.
• Scarsa comprensione da parte degli sviluppatori delle regole aziendali, perché la logica aziendale effettiva è diffusa nel sistema. Questo da solo tende a causare molti bug.
• Tempi di consegna lenti su miglioramenti delle funzionalità o principali regressioni e bug funzionali a seguito del nuovo lavoro di funzionalità.
• Effetti collaterali inaspettati delle modifiche al codice. (In genere, un po 'di codice presuppone che qualche altra parte del sistema avvia una sorta di processo asincrono o una transazione autonoma, ma non ha un modo di verificarlo e un nuovo sviluppatore non conosce questo comportamento o uno sviluppatore esistente si dimentica di esso).
• Una grande divergenza tra il modo in cui gli sviluppatori parlano del sistema e il modo in cui gli utenti ne parlano, risultando in attriti cognitivi quando cercano di dare un senso ai nuovi requisiti.