systemfeld blog
Architektur
Gesucht: Architekturmanager, Niedersachsen
Für einen unserer Partner suchen wir einen Architekturmanager zur Unterstützung bei der strategischen Neuausrichtung eines Fachbereichs (inkl. Plattformwechsel).
Ort: Niedersachsen
Start: ASAP
Dauer: mind. 6 Monate (tendentiell 1 Jahr)
Ref-Nr: VC12-1262
Aufgaben/Themen/Skills
• Design komplexer Software- und System-Architekturen
• Abstimmung mit den Entwicklungsspezialisten
• nachweisliche Erfahrung im Architekturmanagement
Wenn Sie verfügbar und interessiert sind, kontaktieren Sie uns gerne mit Ihrem aktuellen Profil per E-Mail über netzwerk@systemfeld.de oder telefonisch unter 030 25760986.
Möchten Sie den denkbar einfachsten Zugang zu spannenden Projekten und Schulungs- und Coaching-Einsätzen gleichzeitig haben? Werden sie Freies Mitglied im Entwickler-Netzwerk systemfeld. Kostenfrei.
Senden Sie uns zur Anmeldung einfach eine kurze E-Mail mit Ihren Kontaktdaten.
Weitere Projekt- und Consulting-Aufträge finden Sie unter http://blog.systemfeld.de/category/projekte/
TOP5 der besten Software-Bücher aller Zeiten
Diese Liste zeigt meine persönliche TOP5-Liste von Software-Büchern, die ich in der Vergangheit gelesen habe und mir wertvolle Denkanreize für meine tägliche Arbeit gegeben hat. Unser systemfeld-Bücherschrank teilt ich zwei grundlegende Bücher-Bereiche auf:
Der erste Bereich beinhaltet Bücher zu bestimmten Technologien und Frameworks. Durch die schnellen Innovationszyklen und den Fortschritt ist die Halbwertszeit eines Buches aus diesem Bereich bei ca. einem Jahr anzusiedeln – oder darunter. Dann wird es Zeit, es dem Bücher-Himmel anzuvertrauen (es ist unglaublich, wieviel Geld da jährlich in das Altpapaier wandern).
Die Bücher der TOP5-Liste der Software-Literatur kommen aus dem zweiten Bereich unserer Bibliothek: die der Prinzipien und Paradigmen. Diese Bücher enthalten allgemeingültige Gedankenkonstrukte, die sich über viele Jahre Ihre Gültigkeit bewahrt haben, und sind auch heute noch jeden Cent wert.
Die Liste habe ich absteigend sortiert – es soll ja spannend bleiben. Habe ich ein Buch vergessen? Schreibt mir einfach oder hängt es gerne als Kommentar unten dran.
Viel Freude beim Lesen!
PLATZ 5
Das Buch “Anti Patterns – Entwurfsfehler erkennen und vermeiden” der Autoren William J. Brown, Raphael C. Malveau, Hays W. “Skip” McCormick III, Thomas J. Mowbray zeigt mit schönen Beispielen, wie man es NICHT machen sollte. Das Buch erläutet, was ein Pattern ist, wozu es dient und wie man die identifizierten Anti-Pattern nutzen sollte.
Das Erfrischende für Entwickler und Projektleiter ist, dass in diesem Buch nicht nurCode-Fehler oder Architektur-Fehler besprochen werden, sondern auch Fehler, die in der Kommunikation innerhalb des Teams und mit dem Kunden begründet liegen.
Die beste Technik hilft nichts, wenn man nicht weiß, was man bauen soll…
PLATZ 4
Dieses Buch ist des Architekten Best Friend – “Architecture Blueprints”. Es erläutert anhand der gängigen Enterprise-Blaupausen die unterschiedlichen Architektur-Ansätze aktueller Plattformen wie Java Enterprise, Spring, Oracle Forms, SOA, usw. Dadurch bekommt man einen guten Überblick, wie eine Software grundsätzlich aufzubauen und was dabei zu beachten ist.
Im Grunde und in Kürze: Schichten und Entkoppeln.
PLATZ 3
Testen, test, testen. Ja, ja, ja! Aber wie? Und es ist doch so lästig? Aber nein, einfach das Buch “Test Driven Development” von Kent Beck lesen. Der erhebt die Erstellung von Unit-Test nämlich zum Programmierprinzip. Hier werden die Tests nicht nach dem Produktivcode hinterher geschoben, sondern als Bedingung voran geschrieben, die der dahinter zu implementierende Code zu erfüllen hat. Die Vorteile dieser Herangehensweise ergeben sich wie von selbst: Der Code wird leserlicher, es wird nur das programmiert, was benötigt wird, hohe Testabdeckung und kleinere entkoppelte Code-Einheiten.
Wie Weihnachten. Bis alle Lämpchen grün leuchten. Herrlich!
http://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530
PLATZ 2
Dieses Buch erklärt anschaulich, dass eine Problemdomäne für uns Informatiker kein Problem darstellen muss. Man muss es nur richtig machen. “Domain Driven Design” von Eric Evans (sogar mit Vorwort von Martin Fowler). Wie teilt man Domänen am besten auf, welcher Code wird dort eingelagert, wie können Domänne helfen, den Code besser zu strukturieren.
Kein Problem – Domäne.
PLATZ 1
Wer dieses Buch nicht kennt, sollte sich als Informatiker einen anderen Beruf aussuchen – oder es sofort bestellen. DER Klassiker und kommt trotz der in C++ geschrieben Beispiele nicht aus der Mode. Ein wenig Transfer-Leistung muss schon sein. “Design Patterns” der Gang Of Four Erich Gamma, Richard Herlm, Ralph Johnson und John Vlissides.
Dieses Buch zeigt auf, wie Software-Code auf Design-Ebene aufgeteilt, strukturiert und wieder miteinander verbunden werden soll. Die Entwurfsmuster identifizieren Code-Einheiten für die immer wieder anliegenden Aufgaben: das Erzeugen von Klassen, Redo, Antseuern von Objekt-Kompositionen. Da diese Muster so grundlegend und die dazugehörigen Problemlösungen so generell sind, sind sie auf die meisten OO-Sprachen wie Java, C#, usw. leicht übertragbar und bis heute gültig (und werden es noch lange sein).
Autor: Stephan Scharff-Rahn
Herr im eigenen Haus – Die Matrix-Architektur
Einleitung
Die Anforderungen an die Applikations-Entwicklung steigen kontinuierlich mit den Bedürfnissen der Nutzer und dem Fortschritt der eingesetzten Frameworks. Zwar bringen heutige Frameworks einen hohen Vorfertigungsgrad mit, jedoch müssen sie sinnvoll in einer Applikation zu einem runden Ganzen zusammengefügt werden. Wer bei dem Einsatz schwergewichtiger Frameworks und eigenem Code sich nicht an ein paar Spielregeln hält, ist schnell im eigenen Haus nicht mehr Herr und verliert den Überblick.
Dieser Artikel befasst sich damit, wie eine Applikation grundlegendst strukturiert werden sollte, damit alle Bestandteile harmonieren und eine Pflege des Codes vereinfacht wird. Neue Bestandteile sollten einfach hinzugefügt, alte Teile ohne große Auswirkung auf die Gesamtapplikation ausgetauscht und umgeschrieben werden können.
Die folgenden Architektur-Regeln entscheiden darüber, ob eine Migration von Hibernate-Entities zu JPA.Entities ein kleiner Task oder eine Herkules-Aufgabe ist.
Schichten
Ein wichtiges Strukturelement für eine Architektur ist die Schichtung des Applikationsaufbaus. Eine Schicht ist eine Ordnungseinheit, deren Bestandteile eine abgeschlossene technische Aufgabendomäne repräsentieren. Die Besonderheit einer Schicht ist die Aufrufrichtung. Jede Schicht stellt ihre Domäne über eine definierte Schnittstelle zur Verfügung und ruft selber nur unter ihr liegende Schichten auf. Im strengsten Fall nur die, die direkt unter ihr liegt. Der Vorteil einer Schichtung liegt auf alle Fälle darin, Verantwortlichkeiten klar abzutrennen, sie austauschbar zu machen und durch das gerichtete Aufrufparadigma gefährliche Kreisreferenzen zu vermeiden.
PADI
Sie können für Ihre Applikation so viele Schichten definieren, wie Sie für richtig halten. In einigen Fällen eignet sich zur Strukturierung eines technischen Problems eines bestimmte Anzahl von Schichten. Nehmen wir das OSI-7-Schichten-Modell für die Kommunikation zwischen Einzelapplikationen. Es ist ein Raster, welches sich auf fast alle Kommunikationsprotokolle legen lässt und deren Aufbau erklärt. Architekturen von Enterprise Applikationen lassen sich am besten mit dem PADI-Modell aufteilen - dies steht für die vier Schichten Presentation, Application, Domain und Infrastructure.
Software-Schichten PADI
Presentation-Schicht
Diese Schicht stellt die Schnittstelle zum User dar und steuert dessen Interaktion mit der Applikation und die Anzeige der Ergebnisse. Dies ist die Welt von Swing oder Webframeworks wie Spring MVC, JSF, Flex, usw. Sie sind meistens intern nach dem Moder View Controller (MVC) Paradigma aufgebaut und enthalten interne Models, um Daten zur Sicht und User-Aktionen auszutauschen, Controller, die diese Aktionen ansteuern und Views, die die Sichten für den User generieren, wie z.B. HTML oder AMF-Daten zur Flash-Anbindung. Die Controller dieser Schicht sind reine View-Controller zur Verarbeitung der User-Eingaben. Die Verarbeitung dieser Eingaben in Form einer Fachlogik erfolgt nicht in dieser Schicht sondern in der darunter liegenden Application-Schicht.
Application-Schicht
In dieser Schicht befindet sich die Ablauflogik der Applikation. Sogenannte Application-Controller bilden die Hooks zum Aufruf die Fachlogik. Da hier der Ablauf zentral gesteuert wird, sitzt auch hier die Transaktionssteuerung der Applikation und bildet ab hier die Transaktionsklammer für alle Aufrufe, die auf darunterliegende Schichten gehen. Nehmen wir an, in einem Logikablauf werden verarbeitete Daten via Webservice weiter gereicht und zugleich Zusatzinformationen in eine Datenbank geschrieben. Bei einer Exception des Service-Aufrufs muss der Call zurückgefahren werden, zudem auch der Schreibzugriff auf die Datenbank zur Erhaltung der Datenkonsistenz. Die Steuerung (!) der Transaktion kann also nicht in den darunter liegenden Schichten liegen, sondern nur eine jeweiligeTeilausführung wie ein Datenbank-Rollback.
Ist die Logik dieser Controller, wie bei vielen Web-Anwendungen, in flachen Methoden aufgeteilt, redet man sogenannten Transaction Scripts, da der Ablauf einen stark prozeduralen Charakter besitzt. Transaction Scripts sind einfach zu programmieren und zu verstehen, jedoch können bei vielen ähnlichen Logikabläufen Code-Redundanzen entstehen. Sollte so etwas der Fall sein, empfiehlt es sich, ein Teil Logik in die darunter liegende Fachdomäne zu übertragen.
Domain-Schicht
Die Domain-Schicht beinhaltet alle Objekte, die die Fachlichkeit einer Applikation abbilden, die sogenannten Entitäten. Dies sind z.B. bei einem ERP-Programm die Klassen Kunden, Rechnung, Posten, Lager, usw. Bei einem Malprogramm würden sie z.B. Leinwand, Strichstärke, Filter, usw. heißen. Beinhalten diese Objekte viel Logik, nennt man diese Klassen im Verbund ein sogenanntes Rich Domain Model. Befindet sich die Logik überwiegend in den darüber liegenden Application-Controllern, nennt man es ein Thin Domain Model. Die meisten Webapplikationen sind von der zweiten Sorte.
Zustände von Entitäten können transient oder persistent sein. Zum Persistenzieren benutzt die Domain-Schicht die darunter liegende Infrastructure-Schicht. Die Manipulation und Steuerung der Entitäten werden der darüber liegenden Application-Schicht für Data Access Objects (kurz DAO) zur Verfügung gestellt. So kann ein Controller über ein DAO eine Entität neu erzeugen oder über einen Schlüssel auslesen.
Es sei hier nochmal darauf hingewiesen, dass selbst bei Vorhandensein von Logik in den Entitäten hier nicht die Steuerung der Transaktionskontrolle sitzt.
Infrastructure-Schicht
Diese Schicht stellt über definierte Schnittstellen den oberen Schichten den Zugriff auf die umgebende Applikationsinfrastruktur zur Verfügung. Dies kann z.B. die Datenbank für die Domain-Schicht sein, die Verbindung zum Email-Server oder einem Legacy-System.
Aufruf-Paradigma
Jede Schicht darf nur die direkt unter ihr liegende Schicht aufrufen: die Presentation- nur die Application-, die wiederum nur die Domain-Schicht. Es ist also verboten, aus einer View direkt auf Entitäten zuzugreifen. Wer einmal viele JSPs ändern musste, weil sich Entitäten geändert haben, wird diesen Aspekt gut nachvollziehen können.
Eine Ausnahme bildet die Infrastructure- Schicht, die von jeder darüber liegenden Schicht aufgerufen werden kann. Eine View braucht den eingehenden Request des Servers, ein Application-Controller JNDI-Variablen und ein DAO einen Datenbankzugriff, usw.
Datenfahrstuhl DTO
Durch das Aufruf-Paradigma von Software-Schichten ist es verboten, dass unten liegende Schicht Objekte aus der Domäne der darüber liegenden Schicht zur Verarbeitung erhält. Nehmen wir die HttpSession, die in vielen Applikationen gerne nach unten gereicht wird, da man darin einfach seine Daten ablegen kann und wieder darauf zugreifen kann. Wenn die unten liegende Schicht ohne Session getestet werden soll, tauchen die ersten Probleme. Man muss die Session mocken. Schlimmer ist nur, wenn ein anderer Client angedockt werden soll, der diese Session gar nicht kennt. Der größte Nachteil ist die Kreisabhängigkeit, das sich beide Schichten sich immer gegenseitig kennen müssen. Eine Auftrennung oder Tausch einer Schicht wird so gut wie unmöglich.
Um diesem Problem aus dem Wege zu gehen, werden Data Transfer Objects (kurz DTOs) eingesetzt. Sie sind in der Infrastructure-Schicht angesiedelt und bilden einen separaten Datenfahrstuhl innerhalb der Applikation. Dadurch sind die Schichten leichter austauschbar, weil keine Fremdsignaturen in den Schnittstellen vorhanden sind. Werden z.B. die Daten in Form von Entitäten direkt nach oben gereicht, kann dies böse Überraschungen bringen. Dies ist der Fall, wenn bei der Änderung von Entitäten alle davon beteiligten Schnittstellen mit geändert werden müssen.
Wandelt man die Daten jedoch vorher in eigene DTOs , hat man in allen Schnittstellen ein Eigenformat, was unabhängig von der eingesetzten Technologie sowie Frameworks ist.
Für die Wandlung der Daten von DTOs zu Schicht-Objekten können Mapper manuell erzeugt werden oder Frameworks wie Dozer eingesetzt werden.
Matrixarchitektur durch Fachkomponenten
Die vertikale Aufteilung durch Schichten unterteilt eine Applikation in ihre technischen Zuständigkeiten. Eine Applikation besteht jedoch nicht nur aus einem technischen sondern auch aus fachlichen Aspekten. Die Fachlichkeiten einer Applikation teilen wir in sogenannte Fachkomponentenn auf, die die Applikation horizontal aufteilt. Sie fassen über alle Schichten eine fachliche Domäne zu einer Einheit zusammen. Wie bei den Schichten kann eine Fachkomponente andere aufrufen, die Aufrufe sollten wieder gerichtet sein, so dass keine Kreisabhängigkeiten entstehen.
Ist eine Applikation in vertikale Schichten und horizontale Fachkomponenten aufgeteilt, spricht man von einer Matrixarchitektur.
Matrixarchitektur
Wie auf einem Schachbrett hat jeder Code-Bestandteil seinen definierten Platz. Man findet sich in dem Code sofort zurecht und weiß, wo man was zu finden hat. Besonders, wenn diese Matrix auf den Code abgebildet wird, in dem man die Packages der Klassen danach benennt. Ein Aufbau könnte sein:
[projekt].[fachkomponente].[schicht].[weitere Unterpackages]
Daraus abgeleitete Beispiele:
- de.systemfeld.accounting.application.controller
- de.systemfeld.accounting.domain.dao
- de.systemfeld.accounting.domain.entities
Wenn ein Architekt so eine Matrix für eine Applikation entworfen hat, kann er mit Tools wie SonarJ überwachen, ob sich alle Entwickler an die vorgegebene Architektur halten. Tools wie SonarJ prüfen die Sourcen, ob Aufrufe und deren Richtungen sich an die Vorgaben halten. Dass eine Aufrufrichtung nicht eingehalten wurde, kann ganz einfach an den Imports einer Klasse erkannt werden. Importiert eine Klasse eine weitere Klasse aus einer falschen Schicht, z.B. ein Application-Controller kennt den Request, ist dieser Verstoß schnell auffindbar.
Fazit
Der Vorteil der Aufteilung einer Applikation in eine Matrixarchitektur ist mannigfaltig. Je größer und komplexer eine Anwendung wird, um so schwerer ist es, darin Ordnung zu halten. Es kommen im Laufe der Zeit durch neue Programmierer Anbauten hinzu, die nicht zum Gesamtbild passen. Durch falsche Schichtaufrufe können Abhängigkeiten entstehen, die bei einer möglichen Migration einer der eingesetzten Technologien wie z.B. der OR-Mapper, schwer auftrennbar sind.
Dieses Raster gibt dem Architekten eine Basis, die Bestandteile einer Applikation richtig einzuordnen. Ein weiterer Vorteil ist, dass durch dieses Raster ein gemeinsamer Wortschatz aufgebaut wird und jeder im Team weiß, wo er welchen Code-Teil zu finden hat und wo neue Teile eingebaut werden sollen. Die Überprüfung der entworfenen Ordnung mit Tools wie SonarJ rundet das Konzept ab, so dass ein Architekt immer Herr im eigenen Haus bleibt.
Autor: Stephan Scharff-Rahn
