Non sono sicuro che ci sia una risposta qualsiasi, ma piuttosto molte (probabilmente supponenti) risposte.
Ciò di cui stai parlando potrebbe generalmente rientrare in Processo di sviluppo software o Metodologie di progettazione, come Domain-driven_design . Lo spazio è abbastanza grande e, Wikipedia ha una buona (ma più che probabile incompleta) ontologia sullo sviluppo del software, e, potresti trovare quello che stai cercando o almeno la terminologia di alcuni dei tuoi obiettivi. DDD parla di stabilire un vocabolario all'interno di un contesto e si concentra anche sull'individuazione dello stato persistente e dei collegamenti (esterni e interni). DDD stabilisce un contesto per lo sviluppo di servizi. (C'è quasi sempre un altro contesto più ampio, però!)
Altri raccomandano processi come Test Driven Development, dove casi di utilizzo e altri scenari sono sviluppati come test, in primo luogo, quindi software sviluppato per risolvere i nuovi test falliti.
Alcuni come Business Process Modeling , dove l'idea è di scomporre il problema in processi, che spesso assomigliano ai diagrammi di flusso. Non mi interessa perché preferisco la nozione di servizi (che si focalizzano più sulle interfacce visibili esternamente) come un'astrazione sulla nozione di processi, che tendono a focalizzarsi troppo sui dettagli di implementazione interna.
Il nostro compito come programmatori è di realizzare una soluzione orientata al dominio utilizzando la nostra gamma di linguaggi e framework di programmazione. Fondamentalmente stiamo creando una mappatura live (che include comportamenti) tra il dominio aziendale e il dominio della tecnologia informatica su cui i computer operano più naturalmente.
Sei sulla strada giusta iniziando con concetti orientati al dominio (i nomi) e traducendoli in concetti IT. Le astrazioni scelte sono scelte significative nel processo di progettazione. (I verbi, ovviamente, possono tradursi in metodi o funzioni.)
Ho notato che il tuo approccio non include la scomposizione ricorsiva. A volte una data entità è sufficientemente complessa da non essere attuabile direttamente. Quindi, alcune entità sono scomposte in un numero di quelle più piccole, che possono diventare classi, a meno che non si decompongano. Le classi non sono l'unica astrazione, per esempio, abbiamo anche spazi dei nomi che aiutano ad organizzare le classi, quindi forse un concetto che si decompone in più classi ottiene il proprio spazio dei nomi.
Il refactoring è anche un approccio significativo al processo di sviluppo del software iterativo. Iniziamo, quindi troveremo più spazio per il miglioramento delle funzionalità esistenti, quindi modificiamo / miglioriamo il design indipendentemente dall'aggiunta di nuove funzionalità.
Scrum, Agile, lean, anche altri approcci dovrebbero essere considerati.
Hai descritto un programma come prendere input e produrre output. Molti programmi hanno bisogno di vivere più a lungo di una singola sessione, ad esempio supportando più utenti. Molti programmi in questi giorni richiedono anche uno stato persistente, che può significare utilizzare un database, quindi a volte i nomi si traducono anche in entità relazionali.
Ci sono anche molte scelte di tecnologie da considerare. Database, framework ORM, framework UI, linguaggi di programmazione, ecc.
Inoltre, ci sono metodologie su come ottenere una migliore immagine iniziale, che va a migliorare le specifiche che potresti iniziare come input per il tuo algoritmo iterativo. Forse DDD potrebbe aiutare anche lì, oltre al campo più generale della raccolta dei requisiti.
Anch'io sono un grande fan della stratificazione. La stratificazione è una forma di modularità, la cui idea è presentare un insieme coerente di astrazioni per il livello successivo. Quel prossimo livello dovrebbe usare solo lo strato immediatamente sottostante, e specialmente niente più in basso. Quel prossimo livello poi fa la stessa cosa (presenta un insieme coerente di astrazioni) per il suo livello superiore. Questo meccanismo organizzativo aiuta con basi di codice molto grandi.
Naturalmente, molti di questi approcci di sviluppo del software possono essere usati insieme. Vedi anche altre metodologie