Refactoring nella progettazione guidata dal dominio [chiuso]

Ho appena iniziato a lavorare su un progetto e stiamo usando la progettazione guidata dal dominio (come definito da Eric Evans in Domain-Driven Design: Tackling Complexity in the Heart of Software . Credo che il nostro progetto sia sicuramente un candidato per questo progetto modello come Evans lo descrive nel suo libro.

Sto lottando con l'idea di refactoring costantemente.

So che il refactoring è una necessità in qualsiasi progetto e accadrà inevitabilmente quando il software cambia. Tuttavia, nella mia esperienza, il refactoring si verifica quando cambiano le esigenze del team di sviluppo, non come cambia la comprensione del dominio ("refactoring per una maggiore comprensione" come lo chiama Evans). Sono più preoccupato per le scoperte nella comprensione del modello di dominio. Capisco apportare piccole modifiche, ma cosa succede se è necessaria una grande modifica nel modello?

Qual è un modo efficace per convincere te stesso (e gli altri) che dovresti refactoring dopo aver ottenuto un modello di dominio più chiaro? Dopotutto, il refactoring per migliorare l'organizzazione o le prestazioni del codice potrebbe essere completamente separato da quanto espressivo in termini di codice linguistico onnipresente. A volte sembra che non ci sia abbastanza tempo per refactoring.

Fortunatamente, SCRUM si presta da solo al refactoring. La natura iterativa di SCRUM semplifica la costruzione di un piccolo pezzo e lo modifica. Ma col tempo quel pezzo diventerà più grande e se avessi una svolta dopo che quel pezzo è così grande che sarà troppo difficile cambiarlo?

Qualcuno ha lavorato a un progetto che utilizza la progettazione guidata dal dominio? Se è così, sarebbe bello avere qualche idea su questo. Mi piacerebbe in particolare ascoltare alcune storie di successo, dal momento che DDD sembra molto difficile da ottenere.

Grazie!

Sono stato un grande fan di 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 usando una nuova metodologia di progettazione. Se ci vorrà un tempo significativo, deve avere un vantaggio proporzionale al progetto per ottenere quel tempo dalla direzione.

Per quanto riguarda il farlo: in un caso, ho partecipato a un grande refactoring di 3 mesi a causa di una "svolta" nella comprensione del modello di dominio. Richiedeva test per verificare il comportamento corrente, test per verificare il comportamento previsto e modifiche al codice chiamante. I vantaggi erano tuttavia significativi e consentivano all'azienda di fare molte più cose che prima dovevano fare ma che proprio non era in grado di fare. In sostanza, il refactoring era essenzialmente una "caratteristica".

Il refactoring in Domain Driven Design è, credo, guidato da un'esigenza, non da un "simpatico" refattore. Non appena si identifica un modello di dominio errato, il codice / sistema non rappresenta il problema del mondo reale.

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

Inizialmente abbiamo identificato nel modello i 2 tassi erano completamente separati e non avevano alcuna relazione se non attraverso il Contratto. Tuttavia, quando abbiamo completato più storie, ci siamo resi conto che erano effettivamente le stesse, soprattutto quando abbiamo iniziato a impacchettare la nuova tariffa come vecchia solo per farla funzionare. Questo è stato il primo segnale di avvertimento.

Per farla breve, siamo riusciti a ottenere il 90% delle storie fatte con il modello errato, ma siamo arrivati ​​al punto in cui in ogni parte del codice stavamo avvolgendo la nuova Tariffa come una vecchia, e / o creando se newRate else oldRate OGNI dove. Stavamo sbattendo la testa contro il proverbiale brickwall. Siamo stati a metà di questa parte del progetto e sapevamo che il tempo necessario per il completamento sarebbe esponenziale o inattuabile con il modello di dominio errato. Quindi abbiamo morso il proiettile, diviso una storia in altre otto storie e riformattato il modello di dominio.

Quando abbiamo completato il progetto, sapevamo dal senno di poi che 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 facessimo, ci sarebbe voluto più tempo. DDD è stato fatto bene? Beh, stranamente non sapevamo del DDD al momento, ma subito dopo abbiamo partecipato a un seminario DDD di Eric Evans, e tutto ciò che io e i miei colleghi abbiamo potuto fare è fare un cenno. Penso che se avessimo conosciuto DDD, avremmo raccolto il refactor molto prima, risparmiando così più tempo.

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

Ciò che ne è risultato è stato il fatto che le persone erano solite modellare in modi in cui non era previsto e quindi interrompevano altre parti del modello per cercare di "farlo funzionare".

Non appena ti rendi conto che c'è qualcosa di sbagliato nel modello di dominio, modificalo il più velocemente possibile. Più tempo ci vorrà prima che tu lo rifletta, 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à. Comprendere che il codice non è come dovrebbe essere un carico cognitivo in più sullo sviluppatore (la differenza tra la nostra comprensione del dominio e l'implementazione corrente) che renderà ulteriori evoluzioni più difficili e / o costose.

La domanda è: "saranno necessarie queste evoluzioni?". Nel Core Domain (l'area che sta facendo la differenza) la risposta è "Sì!". Perché questa è la pozione del dominio di cui l'azienda è più preoccupata e quella che farà la differenza per gli stakeholder. Questo è il luogo in cui desideri mantenere il codice in perfetta forma, pronto a implementare il prossimo requisito con il minimo sforzo, grazie alla flessibilità del tuo modello di dominio.

Tuttavia, sarà costoso se applicato a tutto il codice dell'applicazione. Le aree che non sono così significative per l'azienda ( sottodomini di supporto o generici nel gergo DDD) potrebbero richiedere un approccio meno sofisticato rispetto a quello riservato al core.