© Excellent backgrounds/Shutterstock.com
Java Magazin
Bücher

Bücher: Basiswissen für Softwarearchitekten

Anders als bei anderen Entwicklungsmethoden existiert in manchen agilen Methoden wie Scrum die explizite Rolle eines Softwarearchitekten nicht. Doch auch hier gilt genauso: Ohne eine solide Softwarearchitektur kann das Produkt nur bis zu einem gewissen Grad erfolgreich sein. Sobald es komplexer wird, ist die Rolle des Softwarearchitekten gefordert. Diese Rolle muss nicht unbedingt so heißen, sie kann auch von einer oder mehreren Personen des Teams ausgefüllt werden. Insofern richtet sich das Buch an alle, die mit Softwarearchitektur zu tun haben, bis hin zum einzelnen Entwickler.

Michael Müller


Das International Software Architecture Qualification Board (iSAQB), in dem auch einige der Autoren in offizieller Position aktiv sind, hat sich zum Ziel gesetzt, die Ausbildung zum Architekten voranzutreiben. Und so handelt es sich bei vorliegendem Titel um ein Buch, das auf die Prüfung im Foundation Level vorbereitet. Wer nun ein trockenes Lehrbuch erwartet, wird positiv überrascht sein. Das Buch ist durchaus angenehm zu lesen und so auch für Entwickler und Architekten interessant, die dies nicht zur Prüfungsvorbereitung nutzen.Natürlich startet das Buch, wie die meisten Kapitel, mit der Einbettung des Inhalts in den iSAQB-Lehrplan, sprich einer Auflistung der Lernziele. Und am Kapitelende gibt es dann Fragen als Lernzielkontrolle. Der Teil dazwischen liest sich auch losgelöst vom Prüfungsziel.Das Buch startet mit der Frage nach der Bedeutung von Softwarearchitektur, softwareintensiven Systemen und der Wechselwirkung mit deren Umgebung. Unterschiedliche Entwurfsstrategien, von der Vogelperspektive zum Detail, von der Komponente zum System, werden betrachtet. Die Autoren manifestieren, dass beide Strategien abwechselnd und iterativ zu nutzen seien, um inkrementell zu einer tragfähigen Architektur zu gelangen. Sie gehen auf Themen wie Domain-driven Design, Aspektorientierung, lose Kopplung, Inversion of Control, Architektur- und Entwurfsmuster und weitere Techniken ein – Themen, die einem guten Softwareentwickler zumindest in Teilen geläufig sein sollten. Hier werden sie zusammengebracht, um so eine tragfähige Architektur zu schaffen. Ein guter Architekt darf – oder besser muss – auch selbst coden.Softwarearchitektur ist den Stake­holdern zu kommunizieren. Dazu werden Bausteine, je nach Zielpublikum, als Blackbox dargestellt oder ihr Innenleben schrittweise offengelegt, bis hin zu einem bedingt codierfähigen Level – und nicht weiter. Dabei, so betonen die Autoren, darf die Dokumentation kein Selbstzweck sein oder anderswie ausarten. Und sie muss stets aus Sicht des Zielpublikums erstellt werden. Wichtige Tipps halten sie im entsprechenden Kapitel bereit.In den letzten Kapiteln geht es dann um Softwarequalität inklusive ihrer Überprüfung und schließlich um Werkzeuge für den Softwarearchitekten. Werkzeuge, die in Teilen vielen Entwicklern bekannt sein dürften. Hier wird erkennbar, dass Entwickler und Architekten keine disjunkten Mengen darstellen müssen. Insbesondere in agilen Projekten wechseln diese Rollen.Das Buch liefert zwar keinen Beispielcode, dafü...

Java Magazin
Bücher

Bücher: Basiswissen für Softwarearchitekten

Anders als bei anderen Entwicklungsmethoden existiert in manchen agilen Methoden wie Scrum die explizite Rolle eines Softwarearchitekten nicht. Doch auch hier gilt genauso: Ohne eine solide Softwarearchitektur kann das Produkt nur bis zu einem gewissen Grad erfolgreich sein. Sobald es komplexer wird, ist die Rolle des Softwarearchitekten gefordert. Diese Rolle muss nicht unbedingt so heißen, sie kann auch von einer oder mehreren Personen des Teams ausgefüllt werden. Insofern richtet sich das Buch an alle, die mit Softwarearchitektur zu tun haben, bis hin zum einzelnen Entwickler.

Michael Müller


Das International Software Architecture Qualification Board (iSAQB), in dem auch einige der Autoren in offizieller Position aktiv sind, hat sich zum Ziel gesetzt, die Ausbildung zum Architekten voranzutreiben. Und so handelt es sich bei vorliegendem Titel um ein Buch, das auf die Prüfung im Foundation Level vorbereitet. Wer nun ein trockenes Lehrbuch erwartet, wird positiv überrascht sein. Das Buch ist durchaus angenehm zu lesen und so auch für Entwickler und Architekten interessant, die dies nicht zur Prüfungsvorbereitung nutzen.Natürlich startet das Buch, wie die meisten Kapitel, mit der Einbettung des Inhalts in den iSAQB-Lehrplan, sprich einer Auflistung der Lernziele. Und am Kapitelende gibt es dann Fragen als Lernzielkontrolle. Der Teil dazwischen liest sich auch losgelöst vom Prüfungsziel.Das Buch startet mit der Frage nach der Bedeutung von Softwarearchitektur, softwareintensiven Systemen und der Wechselwirkung mit deren Umgebung. Unterschiedliche Entwurfsstrategien, von der Vogelperspektive zum Detail, von der Komponente zum System, werden betrachtet. Die Autoren manifestieren, dass beide Strategien abwechselnd und iterativ zu nutzen seien, um inkrementell zu einer tragfähigen Architektur zu gelangen. Sie gehen auf Themen wie Domain-driven Design, Aspektorientierung, lose Kopplung, Inversion of Control, Architektur- und Entwurfsmuster und weitere Techniken ein – Themen, die einem guten Softwareentwickler zumindest in Teilen geläufig sein sollten. Hier werden sie zusammengebracht, um so eine tragfähige Architektur zu schaffen. Ein guter Architekt darf – oder besser muss – auch selbst coden.Softwarearchitektur ist den Stake­holdern zu kommunizieren. Dazu werden Bausteine, je nach Zielpublikum, als Blackbox dargestellt oder ihr Innenleben schrittweise offengelegt, bis hin zu einem bedingt codierfähigen Level – und nicht weiter. Dabei, so betonen die Autoren, darf die Dokumentation kein Selbstzweck sein oder anderswie ausarten. Und sie muss stets aus Sicht des Zielpublikums erstellt werden. Wichtige Tipps halten sie im entsprechenden Kapitel bereit.In den letzten Kapiteln geht es dann um Softwarequalität inklusive ihrer Überprüfung und schließlich um Werkzeuge für den Softwarearchitekten. Werkzeuge, die in Teilen vielen Entwicklern bekannt sein dürften. Hier wird erkennbar, dass Entwickler und Architekten keine disjunkten Mengen darstellen müssen. Insbesondere in agilen Projekten wechseln diese Rollen.Das Buch liefert zwar keinen Beispielcode, dafü...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang