Refactoring in domain driven design [closed]

Sono stato un grande fan del DDD per un po '(con e senza la rete di sicurezza di un framework di test).

L'intero concetto e il ciclo di vita del refactoring non cambiano perché ora stai utilizzando una nuova metodologia di progettazione. Se ci vorrà del tempo significativo, deve avere un vantaggio proporzionale per il progetto al fine di ottenere quel tempo dalla direzione.

Riguardo a farlo: in un caso, ho partecipato a un refactoring 3 month a causa di una "svolta" nella comprensione del modello di dominio. Ha richiesto test per verificare il comportamento corrente, test per verificare il comportamento previsto e le modifiche al codice chiamante. I benefici erano comunque significativi e consentivano all'azienda di fare molte altre cose che prima doveva fare ma non era in grado di farlo. In sostanza, il refactoring era essenzialmente una "feature".

Il refactoring nel Domain Driven Design è guidato da un bisogno, non da un refattore "carino". Non appena identificate un modello di dominio errato, il codice / sistema non rappresenta il problema del mondo reale.

Per esempio, recentemente abbiamo lavorato su un'applicazione di una ragionevole complessità del dominio. Era un sistema di fatturazione / contrattazione e stavamo introducendo un nuovo tipo di tariffa. Stavamo usando un processo agile, scrum di 2 settimane per essere precisi.

Inizialmente identificati nel modello, i 2 tassi erano completamente separati e non avevano alcuna relazione se non attraverso il Contratto. Tuttavia, mentre completavamo altre storie, ci siamo resi conto che in realtà erano uguali, soprattutto quando abbiamo iniziato ad avvolgere la nuova tariffa come una vecchia solo per farlo funzionare. Questo è stato il primo segnale di avvertimento.

Per farla breve, siamo riusciti a ottenere il 90% delle storie fatte con il modello sbagliato, ma siamo arrivati al punto in cui in ogni parte del codice stavamo avvolgendo la nuova Rate come una vecchia, e / o creare se newRate else oldRate EVERY dove. Stavamo sbattendo la testa contro il proverbiale muro di mattoni. Eravamo a metà di questa parte del progetto e sapevamo che il tempo per il completamento sarebbe esponenziale o non funzionante con il modello di dominio errato. Quindi abbiamo morso il proiettile, diviso una storia in otto storie e il refactoring del modello di dominio.

Quando abbiamo completato il progetto, sapevamo che con il senno di poi era la cosa giusta da fare, ed era l'unica cosa da fare per farlo bene.

Ci è voluto del tempo? Sì, ma se non lo avessimo fatto, ci sarebbe voluto più tempo. DDD è stato fatto bene? Beh, stranamente non sapevamo nulla di DDD al momento, ma subito dopo abbiamo partecipato a un seminario sul DDD di Eric Evans, e tutto ciò che io e i miei colleghi potevamo fare è annuire. Penso che se conoscessimo il DDD, avremmo raccolto il refactor molto prima, risparmiando così più tempo.

Se si ottiene qualcosa di sbagliato nel modello di dominio è importante correggerlo. Nella mia esperienza ci siamo persi un po 'nel modo in cui il modello di dominio si collega alle sue diverse entità quando ne abbiamo implementato alcune.

Ciò che ne risultava era che le persone si modellavano in modi per cui non era inteso e rompevano quindi altre parti del modello per cercare di "farlo funzionare".

Non appena ti accorgi che c'è qualcosa di sbagliato nel modello di dominio, cambialo il più velocemente possibile. Quanto più tempo è necessario prima di refactarlo tanto più difficile sarà cambiare rispetto agli utenti, i cui modelli mentali ora sono adattati.

Per alcune parti del codice, il refactoring continuo è eccessivo. Per qualche altra parte del codice (in DDD, il cosiddetto Core Domain ) è una necessità. Capire che il codice non è come dovrebbe essere posto un carico cognitivo aggiuntivo sullo sviluppatore (la differenza tra la nostra comprensione del dominio e l'attuale implementazione) che renderà le ulteriori evoluzioni più difficili e / o costose.

La domanda è: "sarà necessaria questa evoluzione?". Nel dominio principale (l'area che fa la differenza di business) la risposta è "Sì!". Poiché questa è la pozione del dominio, l'azienda è più preoccupata e quella che farà la differenza per gli stakeholder. Questo è il posto in cui vuoi mantenere il tuo codice in perfetta forma, pronto a implementare il prossimo requisito con il minimo sforzo, grazie alla flessibilità del tuo modello di dominio.

Tuttavia ciò sarà costoso se applicato a tutti il codice dell'applicazione. Le aree che non sono significative per il business ( Supporting o Sottodomini generici nel gergo DDD) potrebbero richiedere un approccio meno sofisticato rispetto a quello riservato per il core.