Man at work

Volevasi informare la gentile clientela che il sottoscritto sta lavorando a un whitepaper di piuttosto vasto respiro.
Titolo provvisorio: "Architetture Software: Best practices & Blueprints".

Lo so che come titolo fa un pò schifo, ma consolatevi con quello chè è attualmente lo schema degli argomenti (senza contare che ve l'ho detto che è provvisorio...):
1 "The importance of being Consistent"
1.1 Considerazioni e consigli generali
2. Linee guida per la creazione di nuovi sistemi
2.1 Semplicità
2.2 Omogeneità
2.3 "Separation of Concerns"
3. Architetture stratificate
3.1 Principi e vantaggi
3.2 Sfruttare le librerie sottostanti
3.3 Stratificare il "valore aggiunto"
3.4 Fornire un facile accesso agli strati superiori
4. Consigli di progettazione per librerie software
4.1 Separazione del codice di utilità in librerie per poter essere riutilizzato
4.2 Realizzare API "autonome" e "self-contained" (cioè che per poter essere utilizzate non debbano necessitare di altre librerie esterne)
5. Paradigmi di sviluppo REALMENTE utili
5.1 "Lightweight" Continuous-Integration
5.2 Unit-testing
6. Test
7. Documentazione del codice

Nel caso non fosse chiaro dal precedente elenco mi occuperò di progettazione (pratica) di architetture software, a partire dal basso (ad esempio come progettare una piccola libreria), fino a toccare anche le architetture enterprise (architetture distribuite, SOA, architetture embedded and so on).

Come già detto sono ancora alla fase di raccolta delle idee, ma sin da ora gradirei avere le vostre richieste: "Nicola mettimi un capitolo sull'AOP (Aspected Oriented Programming)", "Nicola che ne dici di parlare di Concurrent Programming", "Nicola e se illustrassi un caso d'uso reale del principio Separation of Concerns?!?", etc. etc.

Nel caso non disponeste di richieste da sottoporre potreste sempre ripiegare su altri tipi di suggerimenti e/o correzioni (bene accette, anche se a seconda di come mi sveglio la mattina).