Extreme Enthusiasm

Summary: these are notes I write while reading the book by Eric Evans.

Pungolato da Gabriele, ho iniziato a leggere Domain-Driven Design. Questi sono i miei primi appunti.

Begin by designing the model. L’argomento del libro è la progettazione del software, ovvero il design. Ci sono autori (come DHH in Getting Real) che sostengono un metodo di progettazione che parte dall’interfaccia utente, che viene realizzata come una facciata priva di logica, allo scopo di ottenere feedback dall’utente. Questo approccio mi pare più adatto a un tipo di applicazioni dove la logica del dominio sia molto semplice, praticamente implicata da quello che si vede nell’interfaccia utente; molte applicazioni web ricadono in questa categoria. Un possibile rischio è l’effetto iceberg, che fa sì che quanto più raffinato è il mock-up dell’interfaccia utente, tanto più irrilevante sarà il feedback che otteniamo mostrandola agli utenti.

Evans invece suggerisce l’approccio opposto: inizia a progettare la logica del dominio. Ottieni feedback dall’utente tramite discussioni di fronte alla lavagna, con sketch di diagrammi di classi, simulando esempi di uso, e dimostrando un prototipo delle classi di dominio, pilotate da un’interfaccia utente minimale.

Attack domain complexity, not technological complexity. Noi sviluppatori abbiamo una naturale tendenza ad innamorarci della tecnologia; divoriamo libri sull’ultimo framework alla moda per applicazioni web o per interfacciare gli oggetti con i database. Ma spesso quello che fa la differenza fra successo e fallimento di un progetto è quanto accuratamente gestisce la complessità inerente del dominio. Dovendo scegliere fra studiare la spec di EJB 3.0 e un libro sulla teoria degli strumenti finanziari derivati, uno sviluppatore probabilmente preferirà la prima. Occorre frenare questa tendenza, e fare uno sforzo cosciente per imparare quello che serve del dominio applicativo.

Model rhymes with implementation. Non bisogna fermarsi allo stadio di diagrammi UML sulla lavagna, o in documenti Visio/Rose/Che-so-io. Bisogna costruire un’implementazione, che segue passo passo il lavoro di analisi del dominio.

Develop a common language. Il nostro obiettivo è creare un linguaggio ubiquo per parlare del dominio. Un linguaggio che sia derivato dal gergo del dominio, distillando i concetti che servono e rendendoli più precisi. Un linguaggio che sia usato a tutti i livelli: nelle conversazioni fra sviluppatori e con gli esperti di dominio, nei diagrammi UML, e nei nomi delle classi e dei metodi.

Pattern language. A dieci anni di distanza dal libro della Gang of Four, i pattern restano uno dei veicoli migliori per insegnare design.

XP works best when the developers are design buffs. L’assunzione di XP è che tutto il team faccia design in ogni momento. Ciò è necessario perché in XP non c’è nessuno che ti fa piovere il design dall’alto; e se non si fa design, si scade nel code & fix, che è la triste norma nella nostra industria. Allora in XP è importante che tutti imparino il più possibile sul design. Fowler in PEAA parla dell’importanza di creare un Domain Model (uno dei suoi pattern preferiti.) Ma non spiega come! Si limita a dire che in un Domain Model uno può sbizzarrirsi a fare design object-oriented. Il libro di Evans invece parla solo di come realizzare il domain model.

Domain modelling is not just “find the nouns.” I sostantivi corrispondono a classi del dominio; ma sono altrettanto importanti le regole del dominio, e le attività che vengono svolte.

Accelerate development. L’obiettivo è arrivare a un punto in cui powerful new features unfold as corollaries to older features. Il buon design serve a questo, non a soddisfare un astratto desiderio di “fare ingegneria.”

This entry was posted on 30 January 2007 at 12:24 and is filed under Agile. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.