Christian Schmidt

Ein Jahr Serverlessentwicklung mit der AWS. Da erlebt man viel Neues was Spaß macht, interessant ist und was einen in den Wahnsinn treibt. Alte Überzeugungen über Architektur und Testautomatisierung greifen plötzlich nicht mehr und es entsteht Komplexität wo man sie nicht erwartet hätte.

Dieser Talk zeigt, wo und wie wir serverless eingesetzt haben, wo die Erwartungen sich erfüllt haben, aber auch wo es nicht so gut lief und serverless nicht die beste Wahl war. Daraus hervorgegangen sind Schwerpunkte und Best Practises über Staging, Testautomatisierung, Architektur und Komplexitätsbewältigung die vorgestellt und gerne diskutiert werden können.

Was bedeutet die Open Access-Transformation für Erwerbung und Bestandsentwicklung? Diese Frage stellt sich in der alltäglichen Erwerbungsarbeit ebenso in der strategischen Diskussion von Geschäftsmodellen und Kooperationsmodellen. Lizenzen mit Open Access-Komponenten und die Abwicklung von Publikationskosten nehmen eine zunehmend wichtige Rolle ein, ersetzen aber noch nicht die klassischen Erwerbungsformen.
Zur Annäherung an das Thema sollen verschiedene Fragen aufgegriffen werden, die sich durch die Integration von Open Access-Modellen in die bestehenden Strukturen der Erwerbung an wissenschaftlichen Bibliotheken stellen. Welche Etatverteilungsmodelle sind geeignet? Kann ein bedarfsorientierter Bestandsaufbau unter publikationskostenbasierten Modellen noch realisiert werden? Welche Rolle wird zukünftig der Katalog spielen? Wie kann die OA-Förderung in Konsortialverhandlungen als Element konsortialer Strategie integriert werden?
Einige dieser Themen werden bereits in der Frühjahrsfortbildung der Kommission für Erwerbung und Bestandsentwicklung behandelt worden sein. Die Veranstaltung enthält einen Bericht über die Ergebnisse dieses Workshops und weitere Vorträge, die das Thema vertiefen.
ReferentInnen sind: Dr. Henriette Rösch (UB Leipzig), Christian Schmidt (UB Chemnitz), Irina Senst (TIB Hannover)

Susanne Göttker¹, Henriette Rösch², Irina Senst³, Christian Schmidt⁴, dbv Kommission Erwerbung und Bestandsentwicklung
¹ULB Düsseldorf, Düsseldorf, Deutschland, ²Universitätsbibliothek Leipzig, Leipzig, Deutschland, ³TIB Leibniz Informationszentrum Technik und Naturwissenschaften Universitätsbibliothek, Hannover, Deutschland, ⁴Universitätsbibliothek der TU Chemnitz, Chemnitz, Deutschland

Tweet

Other people: Susanne Göttker Henriette Rösch Irina Senst dbv Kommission Erwerbung und Bestandsentwicklung

Die hexagonale Architektur ist eine Alternative zur weit verbreiteten 3-tier Architektur basierend aus Controllern, Services und Repositories. Anders als auf Schichten, wird hier das Augenmerk auf Hüllen gelegt, wobei die fachliche Domäne das Zentrum der Architektur bildet. Dieser Vortrag zeigt zunächst die konzeptionellen Eigenschaften der hexagonalen Architektur und ihre Vor- und Nachteile. Im Anschluss wird an einem Beispiel gezeigt, wie man eine klassische 3-tier Architektur in eine hexagonale Architektur überführt und dabei fachliche Themen zentriert.

Wir alle kennen die typische Backendarchitektur bestehend aus Controllern, Services und Repositories. Gewachsen aus der klassischen 3-tier Architektur, wird sie auch heute noch sehr oft in Microservices eingesetzt. Aus der technischen Trennung ergeben sich allerdings in wachsenden Komponenten zusehends Probleme. Oft werden fachliche Themen mit technischen Implikationen vermischt, da nicht klar ist, wo Fachlogik eigentlich verortet werden soll. Im Controller finden sich Datenvalidatoren, im Service Berechnungen und im Repository oder gar direkt in der Datenbank fachliche Vor- und Nachbedingungen. Fachliche Einzelteile werden dann über Komponenten hinweg orchestriert und erhält oft ein dichtes Netz an Abhängigkeiten zwischen den Schichten. Eine Antwort auf die Frage „Was tut meine Software eigentlich?“ wird dadurch immer weiter erschwert und auch die Wart- und Testbarkeit leidet stark darunter. Eine Alternative bildet hier die hexagonale Architektur. Anders als die Top-Down Architekturen, baut sie auf eine Hüllenarchitektur auf, in deren Mitte die fachliche Domäne beheimatet ist. Nur hier werden fachliche Themen behandelt, Vor- und Nachbedingung geprüft und Daten auf Plausibilität geprüft. Als Nebeneffekt erhält man dabei eine zentrale Stelle der „Wahrheit, dieim Code liegt“. Von innen nach außen wird die Domäne von der Applikationsschicht und die Portschicht eingehüllt. Während sich die Applikationsschicht um die Umwandlung technischer Objekte in fachliche und der Orchestrierung zusammenhängender Domainobjekte widmet, bildet die Portschicht die Verbindung in die Außenwelt. Dabei ist unerheblich ob Daten per HTTP in das System gelangen oder per (O/J)DBC in eine Datenbank gestreamt werden.