Microservices und Bounded Contexts: Perfekte Ehe oder ungleiches Paar?

Microservices und Bounded Contexts: Perfekte Ehe oder ungleiches Paar?

Microservices und Domain Driven Design (DDD) zählen nach wie vor zu den Hype-Themen der IT-Szene. Ein paar Sekunden Google-Suche reichen aus, um gleich dutzende Artikel ausfindig zu machen, die wahre Loblieder auf die „Liebesbeziehung“ von Microservices und Bounded Contexts singen. Aber ist das wirklich so? Bilden Microservices und Bounded Contexts die perfekte Ehe oder wird das Thema vielleicht doch zu sehr durch die rosa Brille findiger Consultants betrachtet?

Domain Driven Design ist als ein Konzept entstanden, um die Distanz zwischen den Domänen-Experten und dem Software-Entwicklungsteam und die daraus resultierenden Projektrisiken nachhaltig zu verringern. Eric Evans hat das in seinem Standardwerk „Domain-Driven Design: Tackling Complexity in the Heart of Software“ präzise beschrieben. Ein zentrales Element ist dabei eine gemeinsame Fachsprache, die „Ubiquitous Language“, die aus der Domänen-Story entwickelt und auf allen Ebenen, vom Grobkonzept bis in den Quellcode hinein, angewendet wird. In den meisten Fällen zeigen sich bei der Herleitung der Domain-Story einige Begriffe, die in unterschiedlichen Zusammenhängen (z.B. Abteilungen) andere Bedeutungen haben. Im Domain Driven Design wird in diesem Fall keine sprachliche Lösung geschaffen, sondern eine Grenze um den maximalen Raum innerhalb der Domäne gezogen, in dem jeder Fachbegriff eine einzige, eindeutige Bedeutung hat. Dieser abgegrenzte „Sprachraum“ ist der Bounded Context.

Aus dieser Perspektive wird klar, dass ein Bounded Context – je nach Komplexität der Domäne – ganz unterschiedliche Dimensionen annehmen kann. Die Spanne erstreckt sich von einem sehr kleinen Kontext, der sich durchaus zur Abgrenzung eines Microservice eignen kann, bis hin zu einem gewaltigen, als Microservice untauglichen Kontext-Monolithen. In den meisten Fällen sind Microservice und Bounded Context folglich ein ausgesprochen ungleiches Paar. Der Bounded Context beschreibt die maximale Ausdehnung, die ein Microservice logisch annehmen kann und steht damit geradezu im Widerspruch zu dessen Anforderungen an reduzierte Komplexität und Größe.

Woher rührt dann also der Hype? Nun, zum einen sind Bounded Contexts eine Möglichkeit, erste Schnitte im Projekt anzusetzen und bieten damit zumindest eine Annäherung. Zum anderen ist jeder Bounded Context ein Cluster, in dem mehrere zu definierende (Micro-)Services durch die Ubiquitous Language logisch verbunden sind. Auch das kann bis hin zur Evolution der Microservice-Landschaft eine Menge Vorteile bringen.

Für die Microservices selbst und deren Abgrenzung stellt Domain Driven Design das Konzept der internen Bausteine (Internal Building Blocks) mit vielen nützlichen Patterns zur Verfügung. Das vielleicht wichtigste dabei sind die Aggregates, die als kleinste sinnvolle Einheit für einen Microservice sozusagen den Gegenpol zu den Bounded Contexts bilden.

Anhand dieser Betrachtungen lassen sich die Ausgangsfragen klar beantworten: „Die perfekte Ehe“ lässt sich auf der Ebene von Microservices und Domain Driven Design schließen. Bounded Contexts sind für diesen Bund ein wertvoller Beitrag – unter vielen anderen.

Einen tieferen Einblick in Microservice-Architekturen und Domain Driven Design vermittelt das Trainings-Doppelpack „Flexible Architekturmodelle (FLEX)“ und „Domain Driven Design (DDD)“ der ITech Academy.

Weiterführende Links:
Training „iSAQB Domain Driven Design (DDD)“
Training „iSAQB Flexible Architekturmodelle (FLEX)“

 


Bildrechte (Montage):
Halfaral [CC BY-SA 3.0], von Wikimedia Commons

Die Ubiquitous Language der Softwareentwicklung

Die Ubiquitous Language der Softwareentwicklung

IT-Teams sind schon ein Volk für sich, und das ist durchaus positiv gemeint. Die ITler bilden oft einen „fachlichen Mikrokosmos“ im Unternehmen und bleiben gerne unter sich. Das heißt aber noch lange nicht, dass Entwickler, Architekten, Scrum Master, Tester, Deployment Manager und Projekt­manager auch nur ansatzweise eine Sprache sprechen – von Abteilungsleitung und Management einmal ganz abgesehen. Unterschiedliche Ausbildungswege und fachliche Schwerpunkte, aber auch individuelle Unternehmens- und Projekterfahrungen führen in der Regel dazu, dass Fachtermini nicht durchgängig bekannt sind oder von Mitarbeiter zu Mitarbeiter anders verstanden werden. Die resultierenden Missverständnisse können gravierende Auswirkungen auf Effizienz und Projekterfolg haben und im Zweifel eine Menge Geld kosten. Aber was tun?

Ein Lösungsansatz, auf den immer mehr Unternehmen ihr Augenmerk richten, findet sich in der teamweiten Grundlagen­schulung. Der Foundation Level des Weiterbildungsprogramms zum Certified Professional for Software Architecture (CPSA-F) nach iSAQB-Standard hat sich dafür bestens bewährt. In einem dreitägigen Intensivtraining erhalten die Teilnehmer eine umfassende Einführung in die relevanten Definitionen, Methoden und Techniken der Softwarearchitektur und entwickeln so eine gemeinsame Wissensbasis und Sichtweise für die Softwareprojekte, kurzum: eine universell verfügbare Fachsprache (Ubiquitous Language). Die architektonische Perspektive hat sich dabei als sinnvoll erwiesen, da die Teilnehmer die Softwareentwicklung stärker als Gesamtkonzept kennen- und betrachten lernen als durch den fokussierten Blick des Entwicklers. Als willkommenen Nebeneffekt können die Teilnehmer mit einer Abschlussprüfung das anerkannte iSAQB-Zertifikat für den CPSA Foundation Level erlangen.

Für Unternehmen mit limitiertem Fortbildungsbudget bilden Inhouse-Trainings eine kostengünstige Alternative zu den offenen Trainings, wie sie an vielen Standorten in Deutschland regelmäßig stattfinden. Bereits ab einer Größenordnung von 5-6 Teilnehmern können sich Schulungen im eigenen Haus rechnen. Bei einer Auslastung mit 10-12 Personen je Training beträgt das Einsparpotenzial sogar bis zu 50%. Aber nicht nur aus Kostengründen sind Inhouse-Trainings interessant: Wenn ein Zuschnitt der Trainingsinhalte auf eigene Projektanforderungen notwendig ist, gibt es dafür bei Inhouse-Trainings zumeist einen gewissen Spielraum. Bei offenen Schulungen bleiben individuelle Anliegen für gewöhnlich auf die eine oder andere Zwischenfrage begrenzt. So ist es kein Wunder, wenn Inhouse-Trainings in den vergangenen Jahren einen regelrechten Boom erleben.

Folgen Sie uns auf Twitter und diskutieren Sie diesen Beitrag mit uns. Hier geht’s zu unserem Profil.

Nähere Informationen der ITech Academy:

iSAQB Schulungen (Übersicht)

iSAQB Foundation Level (Training & Termine)

Inhouse Trainings (Information & Anfragen)

Nächstes Training: 19.-21. Februar 2019 in Ludwigshafen

Der stille Erfolgsfaktor agiler Teams.

Der stille Erfolgsfaktor agiler Teams.

Softwareentwicklung in agilen Teams stellt hohe Anforderungen an jedes einzelne Teammitglied. Während den fachlichen Qualitäten für gewöhnlich die höchste Aufmerksamkeit gewidmet wird, fallen die „weichen“ Faktoren naturgemäß mit schöner Regelmäßigkeit unter den Tisch. Das ist gleich aus mehreren Gründen paradox: Scrum dient nicht in erster Linie der Verwaltung von Tasks und deren termingerechter Umsetzung, sondern der Organisation des Teams, das mit der Umsetzung betraut ist. Das bringt zwangsläufig den Faktor „Mensch“ ins Spiel. Im „Daily Scrum“ bleiben oft nicht mehr als zehn Minuten, um die Befindlichkeit der Kollegen, schwelende Konflikte und Unstimmigkeiten im Team zu erfassen. Wer hier nicht eine gehörige Portion Empathie mitbringt, kann schnell mit Problemen konfrontiert werden.
Nicht minder schwierig kann die Situation werden, wenn im Zuge von Continuous Delivery die Grenzen zwischen Entwicklung und Betrieb verwischen oder im Sinne von DevOps komplett aufgehoben werden. Kollegen, die bisher in strikt getrennten „Silos“ ihren Dienst am Projekt leisteten, müssen nun plötzlich und unerwartet Seite an Seite agieren. Eine vergleichbare Szenerie kann entstehen, wenn Entwickler aus ihrem Einzelkämpferdasein in die Paar-Programmierung gelotst werden. In beiden Fällen ist Konfliktpotenzial vorprogrammiert und will erkannt und moderiert werden.
Persönliche Probleme einzelner, offene oder schwelende Konflikte im Team, Missverständnisse durch mangelnde Kommunikation: Das Erkennen und Beseitigen dieser und vergleichbarer Zustände ist für den Projekterfolg ebenso entscheidend wie die fachliche Qualität. Was ein bloß funktionierendes von einem erfolgreichen agilen Team unterscheidet, sind deshalb oft genug die stillen Erfolgsfaktoren, die Soft Skills. Das beginnt bei der sorgfältigen Zusammenstellung des Teams. Aber es lässt sich auch in laufenden Projekten weiter steuern und verbessern.
Mitarbeiter – ob Entwickler oder CEO – kann man in ihren grundlegenden menschlichen Eigenschaften nicht verändern, aber darum geht es auch nicht. Trainierte Soft Skills schärfen das Bewusstsein für kommunikative Situationen, verbessern das Gesprächsverhalten und erhöhen die Sensibilität für Zwischenmenschliches. Allein das kann das Teamplay schon entscheidend verbessern.
Das beiden Trainings Soft Skills für Softwarearchitekten und Agile Softwarearchitektur nach iSAQB-Standard genießen an der ITech Academy einen hohen Stellenwert. Zahlreiche Unternehmen aus unterschiedlichsten Branchen lassen jeden neuen IT-Mitarbeiter in einem offenen Training an der Academy schulen oder holen sich einen Trainer für eine Inhouse-Schulung ins Haus.

Nächste Trainings:
AGILA: 13. Mai – 15. Mai 2019 in Nürnberg
SOFT: 30. Januar – 01. Februar 2019 in Ludwigshafen

Für weitere Informationen:
iSAQB Soft Skills für Softwarearchitekten
iSAQB Agile Softwarearchitektur
Inhouse-Trainings

Continuous Delivery – Der Architekt als Speedmaster

Continuous Delivery – Der Architekt als Speedmaster

Sind es nicht faszinierende Zeiten, in denen ein einzelnes Feature Milliarden an Börsenwert produzieren oder über Nacht vernichten kann? Den Trend, in dem wir uns aktuell bewegen, wurde in einem Vortrag im Rahmen des “Architecture Gathering 2018” unlängst beschrieben: Wir befinden uns in der post-industriellen Ära der hochdynamischen, globalen Märkte und disruptiven Veränderungen. Im Fokus stehen dabei weniger die Entwicklungskosten. Time-to-Market ist der entscheidende Erfolgsfaktor. Wer zuerst kommt und den nächsten Hype inszeniert, hat die besten Chancen auf das große Geschäft.

In der Softwareentwicklung ist Geschwindigkeit längst keine Hexerei mehr. Immer höhere Automatisierungsgrade und ein verändertes Prozessdesign ermöglichen Performancesprünge, die noch vor wenigen Jahren undenkbar schienen. Der Softwarearchitekt ist dabei der zentrale „Driver“, sozusagen der Speedmaster im Projekt. Mit seinem Architekturkonzept steuert er nahezu alle relevanten Parameter, um ein Projekt auf seine Anforderungen auszurichten. Wenn Time-to-Market die Priorität hat, sind flexible Architekturmodelle und Continuous Delivery zumeist die erste Wahl. Erstere schaffen mit weitgehend autarken Komponenten bis hin zu Microservices die Voraussetzungen, um effizient zu entwickeln und über die Continuous Delivery Pipeline fortlaufend zu liefern. Aber schauen wir uns das einmal genauer an.

Ein erster Blick auf Continuous Delivery

Continuous Delivery – kurz „CD“ genannt – beschreibt eine Sammlung von Techniken, Prozessen und Werkzeugen, mit deren Hilfe kurze Entwicklungszyklen und die schnelle Auslieferung von Software-Updates oder produktiven Endsystemen ermöglicht werden. CD zielt darauf ab, jede Entwicklung oder Änderung im Code sofort in eine mehrstufige, weitgehend automatisierte Test-Pipeline zu übergeben und nach erfolgreichem Durchlauf mit dem nächsten Deployment produktiv zu stellen. Typischerweise werden bei den Tests drei Phasen unterschieden: Eine Commit Stage, auf der die Software gebaut und die Unit-Tests durchgeführt werden, eine Accaptance Test Stage für die Integrations-, Akzeptanz- und Systemtests sowie eine dritte Phase, in der gegebenenfalls manuelle Tests und ein Freigabeprozess stattfinden können. Für jede Phase gilt das Prinzip „Stop-the-line“: Bei Ermittlung eines Fehlers wird die Test-Pipeline angehalten, bis das Problem behoben ist. Der Entwickler erhält umgehend Feedback. So können Fehler frühzeitig entdeckt und beseitigt werden.

Continuous Delivery und DevOps

In der Konsequenz durchläuft jeder Softwarestand zigmal die Test-Pipeline und muss entsprechend zigmal auf einer Testumgebung installiert werden. Traditionell liegt die Installation für den Test im Aufgabenbereich des Betriebs. Wie soll sich das in der Praxis darstellen lassen? Betrieb und Entwicklung müssen die Konfiguration der Anwendung und die Deployments in so enger Abstimmung planen, dass eine Trennung der Abteilungen nicht länger gegeben ist. DevOps, die Zusammenlegung von Development und Operations, ist tatsächlich eine notwendige Konsequenz, wenn die Umsetzung von Continuous Delivery zum Erfolg führen soll.

Der Softwarearchitekt im Lead

Wenn wir die angesprochenen Themen zusammennehmen, ist der Softwarearchitekt der einzige im Bunde, der gleichzeitig über die Kompetenz verfügt und frei ist von Interessenskonflikten. Allein deshalb bringt es viele Vorteile, Design und Überwachung von Continuous Delivery Projekten im Aufgabenbereich erfahrener Architekten anzusiedeln. Wir haben gesehen, dass die Konzeption von Continuous Delivery unmittelbar abhängig vom Architekturmodell ist. Der Architekt kann Continuous Delivery also im Flow des Gesamtkonzepts entwickeln – auch das ist ein Argument. Weiterhin ist die Perspektive des Architekten auf die Test-Szenarien naturgemäß weniger Tool-getrieben und er kann aufkommende Konflikte von Entwicklung und Betrieb aus dem Konzept heraus moderieren.

Ein Aufwand, der sich lohnen sollte

Mit Continuous Delivery erweitern Softwarearchitekten ihren Kompetenzbereich um ein Thema, mit dem sie punkten können: Speed! Der Entwickler profitiert von unmittelbarem Feedback aus der Test-Pipeline, von der Verringerung des Risikos in der Entwicklung und einer drastischen Verkürzung der Zeit bis zur Produktivstellung. Neue Features können innerhalb weniger Tage zum Anwender gebracht und bei Bedarf mit Varianten ausgetestet werden. So lassen sich auch höchste Anforderungen an die Time-to-Market erfüllen.

Die wichtigsten Grundlagen und Tools rund um Continuous Delivery sind Teil unseres Trainings „Evolution und Verbesserung von Softwarearchitekturen (IMPROVE)“ auf iSAQB Advanced-Level. Folgen Sie uns auf Twitter und diskutieren Sie diesen Beitrag mit uns. Hier geht’s zu unserem Profil.

Nächstes Training: 05.-07. März 2019 in Ludwigshafen
Weitere Infos: www.itech-progress.com/isaqb-improve/

 


1 Quelle: Uwe Friedrichsen, „Life after Microservices“, zum Artikel auf Slideshare hier klicken

Clean Code als Architekturaufgabe

Clean Code als Architekturaufgabe

In unserem ersten Beitrag der Reihe „Softwarearchitektur verbessern“ greifen wir ein Thema auf, das in den Trainings der ITech Academy und auch in zahlreichen Blog- und Forenbeiträgen immer wieder kontrovers diskutiert wird: Clean Code als Architekturaufgabe. Wer nun fragend zum Himmel oder an die Zimmerdecke schaut, sei an das gleichnamige Buch von Robert Martin erinnert, in dem ein erster zielführender Standard für sauberen Quellcode geschaffen und mit einer Vielzahl sachdienlicher Hinweise zu dessen Strukturierung ausgestattet wurde. Tatsächlich beschreibt Clean Code aber nicht nur eine Arbeitsweise, sondern auch eine Bewusstseinshaltung des Entwicklers dahingehend, sich selbst und Nachfolgende nicht mit faktisch unzureichender Codequalität, unsinnigen Entscheidungen und unpräzisen Designs zu belasten. Der Clean-Code-Entwickler übernimmt Verantwortung nicht nur für das Endprodukt, sondern auch für dessen „inneren Werte“ im Hinblick auf Verständlichkeit und Wartbarkeit.

Zugegeben, das alles bezieht sich auf den Entwickler und seine Arbeit. Es mag deshalb in der Tat verwirren, wenn Architekten angeregt werden, sich mit Clean Code als Verbesserungsansatz in der Softwarearchitektur zu beschäftigen. „Was geht mich der Code an?“ lautet meist die Antwort. „Das ist Sache des Programmierers!“ Die Antwort ist ebenso richtig wie falsch: Mit Clean Code zu arbeiten ist eine strategische Architekturentscheidung, die sinnvollerweise begründet in der Konzeptphase getroffen und vom Management abgesegnet wird. Die Entscheidung wird zumeist im Hinblick auf die langfristige Codequalität und die Weiterentwicklungskosten gefällt, und sie ist anspruchsvoll, wie wir noch sehen werden. Sie kann in einem Projekt eine erhebliche Tragweite entwickeln und Auswirkungen bis hin zur personellen Besetzung der Teams.

Wenn Clean Code eine Architekturvorgabe an ein Projekt ist, liegt sie auch im Verantwortungsbereich des Architekten. Softwarearchitekten in Clean-Code-Projekten sollten deshalb auch in der Lage sein, die Einhaltung der Anforderungen im Projekt zu steuern und den Code auf konsequente Umsetzung zu prüfen, beispielsweise mit Tools wie Sonarqube. Und damit öffnen wir schon mal die ersten beiden Schubladen der Konfliktkommode. Denn zum einen sehen Entwickler die tägliche Codehygiene gerne als einen Teil ihrer Intimsphäre an und verzichten nur zu gerne auf „väterliche“ Kontrollgänge des Architekten. Zum anderen nagt die Umsetzung von Clean Code unaufhörlich speziell an der Ressource, die für den Entwickler ohnehin die knappste ist: Zeit. Zumindest ein leiser Protest im Team scheint damit vorprogrammiert. Aber hatte jemand behauptet, der Job des Softwarearchitekten sei ein leichter?

Es gibt noch eine dritte Schublade, nicht minder relevant: Clean Code als Anforderung muss nicht nur dem Projektteam vermittelt, sondern auch dem Management verkauft werden. Auch das kann durchaus schwierig werden. Moderationsfähigkeit und Überzeugungskraft gehörten deshalb ebenso zum Handwerk des Architekten, wie das methodische und technische Wissen.

Auf dieser Basis stellt sich für uns nicht die Frage, ob Clean Code seinen Platz in einem fortgeschrittenen Architekturtraining haben sollte oder nicht, sondern lediglich, in welchem Umfang und welchem Tiefgang das Thema besprochen gehört. In unserem Training „Evolution und Verbesserung von Softwarearchitekturen (IMPROVE)“ auf iSAQB Advanced-Level versuchen wir, die teilnehmenden Architekten zur Entscheidungsfähigkeit hinzuführen, ob und wann Clean Code in einem Projekt Sinn ergibt. Weiterhin werden die wesentlichen Grundlagen und Tools sowie weiterführende Literatur vorgestellt, um eine Beschäftigung mit dem Thema über die Schulung hinaus zu ermöglichen.

Folgen Sie uns auf Twitter und diskutieren Sie diesen Beitrag mit uns. Hier geht’s zu unserem Profil.

Nächstes Training: 14.-16. November 2018 in Nürnberg
Weitere Infos: www.itech-progress.com/isaqb-improve/

NEU: ITech Academy Friends auf Facebook

NEU: ITech Academy Friends auf Facebook

Entdecken Sie die neue Facebook-Gruppe der ITech Academy und sichern Sie sich als Mitglied 10% Rabatt auf alle offenen Trainings von ITech Progress. Wie es geht? Treten Sie mit einem Klick unserer Gruppe bei und warten Sie auf Ihre Bestätigung durch unseren Administrator. Ab diesem Moment können Sie bei jeder Bestellung über die Website im Nachrichten-Feld das Kennwort “Academy Friends” eingeben und Sie erhalten automatisch den Rabatt auf Ihre nächste Rechnung.

Aber die Facebook-Gruppe ist weit mehr als ein Sparstrumpf für unsere Trainingsteilnehmer. Academy Friends werden laufend über aktuelle Entwicklungen, bevorstehende Trainings, den Auslastungsstatus der nächsten Schulungen oder über Änderungen informiert.

Interessiert? Dann klicken Sie den Button, um nach Ihrer Facebookanmeldung der Gruppe beizutreten.

Wir freuen uns auf Sie!