Le scelte compiute nei progetti software possono avere conseguenze devastanti, come nel caso del sistema di controllo di volo dei Boeing 737 Max 8.
Le considerazioni di Bob Martin sul caso dei due aerei caduti in pochi mesi: http://blog.cleancoder.com/uncle-bob/2019/05/18/737-Max-8.html
Sempre più spesso la progettazione software comporta decisioni che influenzano la qualità della vita delle persone, la loro sicurezza, il lavoro, la società e l’ambiente.
Un talk da SATURN 2017 su come fare un assessment rapido delle architetture software di un’organizzazione, con alcune indicazioni utili per una checklist: How to Perform a Rapid Assessment of Any Software Architecture, di Tim Kertis
Cosa si intende per architettura software guidata da eventi? Martin Fowler lo spiega con chiarezza in una presentazione alla GoTo conference.
Astrazioni per l’ignoto, Abstracting the Unknown, presentazione keynote di Grady Booch a SATURN 2016: su architetture software, agile, domain modeling, UML, outsourcing.
Quanto, quando, cosa e come è importante nella definizione delle architetture software.
SATURN è la conferenza annuale sulle tematiche architetturali del Software Engineering Institute.
Introduzione ai Microservices di Martin Fowler. Questi gli spunti più interessanti:
Arc42 è un framework semplice e concreto per documentare le architetture software. L’impostazione è essenziale, ma completa.
Basato su una serie di template, è stato realizzato da e , ed è usabile gratuitamente e senza vincoli. Prevede come opzione, anche se non obbligatoria, l’uso di UML.
Le caratteristiche di Arc42 vengono spiegate in questa intervista su Software Engineering Radio.
Il diagramma di contesto è la rappresentazione sintetica delle relazioni di un sistema con l’ambiente esterno: input, output, stimoli e risposte.
Non compare fra le tipologie astratte di diagrammi dello Unified Modeling Language, ma può essere comunque ben rappresentato in UML.
Alcune delle possibili forme di rappresentazione sono proposte in questo articolo di Eoin Woods su IEEE Software, Nov.-Dec. 2014.
Come far colloquiare diversi sistemi di frontend (come Web, Android, iOS) con i servizi di backend? Un solo backend comune? Uno per il web, uno per tutti i diversi sistemi mobili? Oppure ancora uno diverso per ogni piattaforma mobile? Il pattern Backends for Frontends, proposto da @samnewman , illustra e valuta le diverse possibilità.
Focalizzare la propria attenzione su aspetti specifici, per affrontare meglio problemi complessi.
L’interazione tra utente e sistema. La logica applicativa. L’accesso ai dati. Ma affrontando un aspetto (un layer, uno strato) alla volta.
È questo uno dei vantaggi principali delle architetture a layer, come argomenta Martin Fowler in PresentationDomainDataLayering , articolo in cui discute anche le ragioni che possono indurci a creare un layer intermedio, oppure a eliminarlo.