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
Archivi categoria: architettura software
Architettura Event-driven
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
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.
Microservices
Introduzione ai Microservices di Martin Fowler. Questi gli spunti più interessanti:
- Rapporto tra microservices e SOA (Service Oriented Architecture). I microservices sono solo uno dei modi in cui la SOA può essere organizzata: senza bus centrale (Enterprise Service Bus), autonomi ed indipendenti.
- Organizzare lo sviluppo per microservices significa, prima di tutto, definire e attuale un modello organizzativo in cui ogni team lavora in modo indipendente. A occhio, maggiori sono le dimensioni del team di sviluppo, più questo modello organizzativo è sensato.
- I microservices hanno senso per fornire servizi di business completi. Avrebbe meno senso definire microservices puramente infrastrutturali.
- Per lavorare a microservices bisogna avere già una forte competenza sulla materia, sul dominio applicativo. Se questa manca, meglio sviluppare prima un monolite e poi, se opportuno, ristrutturarlo estrapolandone i microservizi.
Arc42, per documentare le architetture software
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.
UML: diagramma di contesto
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.
Backends for Frontends
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à.
Architetture a layer, rivisitate
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.
Architetto software, il lavoro migliore
(Negli Usa) secondo la CNN il ruolo di architetto software è quello che ha più prospettive, è meglio pagato e soddisfa di più.
In particolare:
Quality of life ratings:
Personal satisfaction: A | Benefit to society: B | Telecommuting: A | Low stress: A
Architetture a microservizi
Un paio di articoli recenti sullo sviluppo di applicazioni basato su servizi distribuiti.
“Microservices“, di James Lewis e Martin Fowler, descrive le caratteristiche più rilevanti delle applicazioni a microservizi, le relazioni con la Service Oriented Architecture (SOA), gli aspetti organizzativi (come la necessità di non avere responsabilità distinte per sviluppo e manutenzione), gli aspetti relativi ai metodi di progettazione (ad esempio il fatto di definire i servizi basandosi su “oggetti di business” disaccoppiati, e la maggiore difficoltà di effettuare interventi di refactoring).
Fowler è poi tornato sull’argomento in “Microservices and the First Law of Distributed Objects” (dove la prima legge è “non distribuite i vostri oggetti”…), evidenziando in modo più preciso le differenze tra lo stile di sviluppo centralizzato e quello distribuito nella progettazione delle interazioni tra componenti.