p { margin-bottom: 0.1in; line-height: 120%; }
Per il mio metodo, questa è probabilmente la cosa più importante nell'architettura e nella progettazione del software.
- Quando stai per scrivere una soluzione software, devi distinguere tra due domini: il dominio del problema e il dominio della soluzione
- I clienti, il mondo, il business, attraverso il team del prodotto stanno modellando o costruendo il dominio del problema, mentre i buoni architetti software, sono responsabili della progettazione del dominio della soluzione, che include i costrutti, i concetti e la tecnologia con cui la soluzione sarà implementata
- Il dominio del problema e il dominio della soluzione sono descritti utilizzando modelli e concetti.
- I concetti, e specialmente i diversi elementi del modello (entità, relazioni, comportamenti, processi) è ciò che sarà materializzato come elementi del software.
- Un'incoerenza nella definizione dei concetti porterà o ad un modello rotto - un difetto logico che in un momento o nell'altro sarà o:
- Cause a bug (di solito alcuni) - o un piccolo bug, come un piccolo pezzo di funzionalità che non funziona bene, o uno serio
- Cause the solution to be a non-solution - that is, it doesn't match the problem domain
O spesso vedrete architetti o sviluppatori esperti discutere sulla denominazione di un componente software. Potrebbe sembrare assurdo ad uno spettatore, ma è tutt'altro, perché mentre discutono sulla denominazione, la cosa più profonda che accade nelle loro teste è il perfezionamento dei concetti relativi a quell'artefatto software e altri elementi del modello associati ad esso. Si tratta spesso di definire chiaramente la responsabilità delle diverse entità e processi, ecc. del modello, senza troppe aree grigie e certamente senza definizioni contrastanti o pezzi mancanti. - In altre parole - stanno lavorando sull'integrità concettuale del progetto.