Non conosco la risposta, ma è una domanda che mi sono spesso posta mentre progettavo la struttura dei miei sistemi. Il modo in cui ci ho pensato ultimamente è che se l'SRP riguarda "una classe che ha solo una ragione per cambiare", allora cosa ci dice riguardo al cambiamento? La risposta è che non ci dice nulla sul cambiamento. La frase parla solo di classi, non di cambiamenti.
Ho cercato di formulare un corollario sul cambiamento, ma non ho ancora trovato nulla di particolarmente soddisfacente. C'è qualcosa in questa risposta ( link ) in un'altra domanda che mi piace - il modo in cui la risposta menziona differenza tra la facilità di cambiare i tipi e le operazioni, quella risposta mi ha fatto riflettere un po '.
Penso che alla fine dipenda dalla coesione del tuo sistema. Un sistema ben progettato con alta coesione significa che il cambiamento è localizzato in modo prevedibile attraverso le classi, indipendentemente da quanti ce ne siano.
Quindi riassumendo: il carico cognitivo diventa un problema solo quando arriva il momento di apportare un cambiamento alle classi, e se le astrazioni (tipi) nel tuo sistema hanno un'elevata coesione, allora dovresti essere in grado di ragionare sul sistema senza eccessivo carico cognitivo. Se scopri che non puoi ragionare sul codice anche se sembra seguire l'SRP, probabilmente hai un altro S.O.L.I.D. violazione, probabilmente la D o la L.