book

Handbuch moderner Softwarearchitektur

by Mark Richards, Neal Ford

December 2020

Intermediate to advanced

432 pages

12h 12m

German

dpunkt

Read now

Unlock full access

Softwarearchitektur definierenErwartungen an ArchitektenArchitekturentscheidungen treffenKontinuierliche Analyse der ArchitekturBei aktuellen Trends auf dem Laufenden bleibenSicherstellen, dass Entscheidungen eingehalten werdenVielfältige Kenntnisse und ErfahrungenWissen in der Fachdomäne des ProblemsFähigkeiten im zwischenmenschlichen UmgangPolitik verstehen und sich in dieser Sqhäre bewegen könnenÜberschneidungen von Architektur und …Engineering-PraktikenTechnischer Betrieb/DevOpsProzessDatenGesetze der Softwarearchitektur
Architektur und Design im VergleichTechnische BreiteVor- und Nachteile analysierenGeschäftliche Faktoren verstehenDie Balance zwischen Architektur und tatsächlichem Programmieren
DefinitionModularität messenKohäsionKopplungAbstraktheit, Instabilität und Entfernung von der HauptsequenzEntfernung von der HauptsequenzKonnaszenzKopplungs- und Konnaszenzmetriken vereinheitlichenVon Modulen zu Komponenten
Architektonische Eigenschaften, eine (unvollständige) ListeBetriebsrelevante architektonische EigenschaftenStrukturelle architektonische EigenschaftenBereichsübergreifende architektonische EigenschaftenKompromisse und am wenigsten schlechte Architektur

Architektonische Eigenschaften aus domänenspezifischen Anforderungen ableitenArchitektonische Eigenschaften aus funktionalen Anforderungen ableitenFallstudie: Silicon SandwichesExplizite EigenschaftenImplizite Eigenschaften
Architektonische Eigenschaften messenBetriebsrelevante MetrikenStrukturelle MetrikenProzessbasierte MetrikenGovernance und FitnessfunktionenGovernance für architektonische EigenschaftenFitnessfunktionen
Kopplung und KonnaszenzArchitektonische Quanten und GranularitätFallstudie: Going, Going, Gone (»Zum Ersten, zum Zweiten und zum Dritten«)
Anwendungsbereiche für KomponentenDie Rolle des ArchitektenArchitektonische PartitionierungFallstudie: Partitionierung für Silicon SandwichesDie Rolle des EntwicklersArbeitsablauf zur Ermittlung der KomponentenAnfängliche Komponenten ermittelnAnforderungen auf Komponenten abbildenRollen und Verantwortlichkeiten analysierenArchitektonische Eigenschaften analysierenKomponenten restrukturierenKomponentengranularitätKomponentendesignSinnvolle Komponentenaufteilung ermittelnFallstudie: Going, Going, Gone: Komponenten ermittelnRückblick auf das architektonische Quantum: Die Wahl zwischen monolithischen und verteilten Architekturen
GrundmusterBig Ball of Mud (Der »große Matschklumpen«)Eingliedrige ArchitekturClient/ServerMonolithische und verteilte ArchitekturenIrrtum Nr. 1: Das Netzwerk ist verlässlichIrrtum Nr. 2: Die Latenz ist gleich nullIrrtum Nr. 3: Die Bandbreite ist unendlichIrrtum Nr. 4: Das Netzwerk ist sicherIrrtum Nr. 5: Die Topologie ändert sich nieIrrtum Nr. 6: Es gibt nur einen AdministratorIrrtum Nr. 7: Die Transportkosten sind gleich nullIrrtum Nr. 8: Das Netzwerk ist homogenWeitere Überlegungen zum verteilten Rechnen
TopologieVoneinander isolierte SchichtenSchichten hinzufügenZusätzliche ÜberlegungenGründe für den schichtbasierten ArchitekturstilBewertung der architektonischen Eigenschaften
TopologiePipesFilterBeispielBewertung der architektonischen Eigenschaften
TopologieKernsystemPlug-in-KomponentenRegistryKontrakteBeispiele und AnwendungsfälleBewertung der architektonischen Eigenschaften
TopologieTopologische VariantenServicedesign und GranularitätDatenbank-PartitionierungBeispielarchitekturBewertung der architektonischen EigenschaftenWann man diesen Architekturstil verwenden sollte
TopologieBroker-TopologieMediator-TopologieAsynchrone FähigkeitenFehlerbehandlungDatenverlust verhindernBroadcast-FähigkeitenRequest-ReplyRequest- oder eventbasiert?Hybride eventbasierte ArchitekturenBewertung der architektonischen Eigenschaften
Allgemeine TopologieVerarbeitungseinheitVirtualisierte MiddlewareData PumpsData WriterData ReaderDatenkollisionenCloudbasierte und On-Premises-Implementierungen im VergleichRepliziertes Caching im Vergleich mit verteiltem CachingÜberlegungen zu Near-CacheImplementierungsbeispieleSystem zum Verkauf von VeranstaltungsticketsOnline-AuktionssystemeBewertung der architektonischen Eigenschaften
Geschichte und PhilosophieTopologieTaxonomieDienste für die GeschäftslogikUnternehmensdiensteApplikationsdiensteInfrastrukturdiensteOrchestrierungs-EngineNachrichtenflussWiederverwendbarkeit und KopplungBewertung der architektonische Eigenschaften
GeschichteTopologieVerteiltBounded ContextGranularitätDatenisolationAPI-SchichtBetriebliche Wiederverwendung (Operational Reuse)FrontendsKommunikationChoreografie und OrchestrierungTransaktionen und SagasBewertung der architektonischen EigenschaftenWeiterführende Referenzen
Architekturstile als »Modeerscheinungen«EntscheidungskriterienMonolith-Fallstudie: Silicon SandwichesModularer MonolithMicrokernelVerteilte Architektur, Fallstudie: Going, Going, Gone
Antipatterns für ArchitekturentscheidungenAntipattern: Covering your AssetsAntipattern: Groundhog DayAntipattern: Email-Driven ArchitectureArchitektonisch wichtigArchitecture Decision Records (ADR)GrundstrukturADRs speichernADRs als DokumentationADRs für Standards verwendenBeispiel
Matrix zur RisikobewertungRisikobewertungRisk StormingIdentifizierungKonsensRisikoanalyse von Agile StoriesRisk-Storming-BeispieleVerfügbarkeitElastizitätSicherheit
DiagrammeWerkzeugeStandards für Diagramme: UML, C4 und ArchiMateRichtlinien für die Erstellung von DiagrammenPräsentierenZeit manipulierenInkrementeller AufbauInfodecks im Vergleich mit PräsentationenFolien sind nur die Hälfte des VortragsUnsichtbarkeit
Teams den richtigen Rahmen vorgebenArchitekten-PersönlichkeitenDer KontrollfreakDer Sofa-ArchitektDer effektive ArchitektWie viel Kontrolle?Warnsignale des TeamsChecklisten einsetzenEntwickler-Checkliste für die CodefertigstellungCheckliste für Unit- und funktionales TestingSoftware-Release-ChecklisteOrientierung bietenZusammenfassung
Verhandlung und ModerationMit geschäftlichen Entscheidungsträgern verhandelnMit anderen Architekten verhandelnMit Enwicklern verhandelnDer Softwarearchitekt als FührungskraftDie vier Ks der ArchitekturSeien Sie pragmatisch, aber visionärTeams mit gutem Beispiel vorangehenAbstimmung mit dem EntwicklungsteamZusammenfassung
Die 20-Minuten-RegelEin persönliches Radar entwickelnDas ThoughtWorks Technology RadarOpen-Source-VisualisierungenSoziale Medien verwendenRat zum Abschied

Content preview from Handbuch moderner Softwarearchitektur

KAPITEL 10

Der schichtbasierte Architekturstil

Einer der häufigsten Architekturstile ist der schichtbasierte oder n-gliedrige (n-tiered) Architekturstil. Dies ist der De-facto-Standard für die meisten Applikationen, hauptsächlich aus Gründen der Einfachheit, Bekanntheit und wegen der geringen Kosten. Dieser Stil ist außerdem eine sehr natürliche Art, Applikationen zu entwickeln. Der Grund hierfür ist Conwas Gesetz (https://oreil.ly/Rb4uN), nach dem die entwickelten Systeme die Kommunikationsstruktur des Unternehmens widerspiegeln. In den meisten Unternehmen gibt es Entwickler für Benutzerschnittstellen (UI), für das Backend, für Regeln und Datenbank-Experten (DBAs). Diese organisatorischen Schichten passen wunderbar zu den Teilen einer traditionellen ...