Archiv

Posts Tagged ‘Architektur’

Buch-Rezension zu “Patterns of Enterprise Application Architecture”

21. August 2013 1 Kommentar

Patterns of Enterprise Application ArchitectureEgal mit was für einer Technologie oder Framework man sich beschäftigt, das Buch “Patterns of Enterprise Application Architecture” von Martin Fowler wird wohl ein Kapitel dazu beinhalten.

MVC? OR-Mapper? Lazy-Loading? Unit of Work? Layering? Session State? Oder braucht man Tipps zur Strukturierung von Geschäftslogik? Fast jedes Thema das man beim Schreiben von Geschäftsanwendungen antrifft wird in diesem Buch behandelt und dessen Platz im grossen Puzzle erklärt.

 

Teil 1: Eine Übersicht zu Geschäftsanwendungen und deren Problemstellungen

Auf rund 100 Seiten erhält man eine Übersicht über die einzelnen Teile die eine Geschäftsanwendung ausmachen. Die Problemstellung wird so erklärt das man auch als Einsteiger in dieses Thema problemlos folgen kann.

Neben einer Definition der Begriffe erfährt man wo die Herausforderungen liegen und wie man durch eine geschickte Wahl der passenden Entwurfsmuster den eigenen Code von den häufigsten Problemen fernhält.

Wer sich schon länger mit Geschäftsanwendungen beschäftigt kann diesen Teil getrost überspringen. Man wird die besprochenen Probleme schon selber oft genug erlebt haben und möchte wohl gleich zu den passenden Lösungen im 2. Teil.

 

Teil 2: Die Patterns

Die Muster sind thematisch geordnet und nehmen die Reihenfolge aus dem 1. Teil auf. Dies macht das Buch sehr angenehm zu lesen da man so auf ein wildes hin und her springen verzichten kann.

Jedes dieser Muster wird nach dieser Schablone erklärt:

  1. Welche Probleme lassen sich damit lösen
  2. Ein UML-Diagramm
  3. Detaillierte Erklärung wie das Pattern funktioniert
  4. Eine Empfehlung wann man dies einsetzen soll (und wann nicht)
  5. Weiterführende Unterlagen
  6. Ein Beispiel mit Code in C# oder Java

Der grösste Nutzen liegt aus meiner Sicht nicht bei der Vorstellung der Patterns an sich, sondern beim Auflisten der Vor- und Nachteile. Stösst man im Projekt an Grenzen kann man entweder alles umbauen oder hier nachschauen was Fowler für Anpassungen empfiehlt. Dabei aber unbedingt überprüfen ob die von Fowler erwähnten Einschränkungen nicht zu noch grösseren Problemen führen. Sonst steht man nach viel Arbeit wieder an der gleichen Stelle.

 

Katalog der Enterprise Application Patterns

Wie für die Refactoring-Patterns gibt es von Martin Fowler auch einen Katalog zu den Enterprise Application Patterns. Darin werden die Patterns mit einer kurzen Beschreibung und dem UML-Diagramm vorgestellt. Dies genügt um sich über die Patterns zu unterhalten, wer allerdings eine Anwendung bauen will wird nicht um das Buch herum kommen.

 

Fazit

Mit Ausnahme von REST erklärt dieses Buch alles was heute bei den meisten Geschäftsanwendungen zum Einsatz kommt. Dabei handelt es sich nicht um irgendwelche an den Haaren herbeigezogenen Spezialfälle, sondern um konkrete Lösungen zu konkreten Problemen.

Wenn man auch intuitiv auf zahlreiche Lösungen selber kommen kann ist dieses Buch doch eine sehr hilfreiche Sammlung. Dies vor allem da auch Alternativen gezeigt und Einschränkungen offen angesprochen werden.

 

Zum Buch

Patterns of Enterprise Application Architecture” von Martin Fowler, 2002 Addison-Wesley, ISBN 978-0-3211-2742-6, 560 Seiten, Englisch

Schlagworte: , ,

Von fachlichen und technischen Daten

31. Juli 2013 Kommentare aus

In einer Geschäftsanwendung werden vor allem fachliche Daten bearbeitet. Daneben gibt es aber eine ganze Reihe von technischen Daten (wie einer ID oder einem Erstelldatum). Diese beiden Arten von Daten können problemlos nebeneinander abgelegt werden. Sobald man allerdings beginnt die Grenzen zu verwischen fangen die Probleme an.

Bis sich die Auswirkungen dieser Vermischung bemerkbar machen kann man sich meist nicht mehr an die dazugehörigen Entscheidungen erinnern. So beginnt ein mühsames Suchen nach den Ursachen von teils äusserst seltsamen Fehlern.

Ich will gar nicht zusammenrechnen wie viele Stunden ich so verloren habe. Dabei waren es zu Beginn jeweils ganz kleine Entscheidungen die am Ende zu solchen Problemen führten. Wie klein die sein können soll das nachfolgende fiktive Beispiel rund um Auftragsformulare zeigen.

 

Wenn aus technischen Daten fachliche werden…

Meist beginnt alles mit einer kleinen zusätzlichen Anforderung. Neu soll beispielsweise das Eingangsdatum eines Formulars geführt werden. Man kann nun ein zusätzliches Feld “Eingang” anlegen oder den Wert ins Feld “Erstellt” hineinschreiben. Das ist ja für die Anwendung das gleiche, da alle Formulare beim Eintreffen erfasst werden.

Allerdings wird das Feld “Erstellt” durch die Anwendung hinweg immer als technisches Feld betrachtet das man weder auf der Oberfläche anzeigt noch irgendwie sonst verwendet. Damit ist es nun vorbei. Für das Objekt “Formular” wird das Feld “Erstellt” nicht nur angezeigt sondern auch noch gleich umbenannt – allerdings nur auf der Oberfläche. Und in den Reports. Und im Export. Und bei allen anderen zukünftigen Verwendungen dieses Objekts.

 

… und dies zu Problemen führt

Die Sonderregelung für “Formular” ist zu diesem Zeitpunkt schon aufwändig aber noch kein Problem. Dazu braucht es meist noch eine kleine Veränderung der Geschäftsabläufe, wie einer externen Erfassung der Formulare.

Um diese externe Erfassung zu ermöglichen kommt dann oft eine Excel-Liste als Transfermethode zum Einsatz. So müssen die externen Sachbearbeiter nichts Neues lernen und im Zielsystem wird eine kleine Importfunktion hinzugefügt. Soweit ist dies ebenfalls noch kein Problem. Doch was soll nun ins Feld “Erstellt” geschrieben werden? Das Datum an dem die Daten importiert wurden oder das Eingangsdatum?

Aus fachlicher Sicht muss das Eingangsdatum gesetzt werden, da sich zwischen dem Eingang und dem Import Preise verändert oder Fristen abgelaufen sein könnten. Aus technischer Sicht wird das Formular mit dem Import erstellt.

Das Problem ergibt sich sobald beide Sichten “ihr” Datum benötigen. Das technische Erstelldatum könnte beispielsweise für einen Report zur internen Kostenverrechnung dienen. Wird dieser Report nach Eingang aber vor dem Import der Formulare ausgeführt stimmen die Werte nach dem Import nicht mehr mit dem Datenbestand in der Applikation überein. Die importierten Formulare fehlen im Report, werden daher nicht verrechnet und Ende Jahr gilt es zu klären woher die Differenz kommt.

 

Ursachen

Bei den Fällen die mir bekannt sind war die Ursache oft eine verfrühte Optimierung oder der krampfhafte Versuch Diskplatz zu sparen. Weder der zusätzliche Speicherplatz noch der Aufwand ein Feld mehr anzulegen hätte man bemerkt. Im Gegensatz zu all dem Aufwand zum Aufspüren der fehlerhaften Auswertungen.

Bitte beachten: DRY (Don’t repeat yourself) gilt nur wenn es sich wirklich um die gleichen Dinge handelt. Andernfalls ist dies keine Repetition sondern erfüllt einen anderen (unabhängigen) Zweck.

 

Wie verhindern?

Im obigen Beispiel hätte man spätestens als die Importfunktion erstellt wurde die Datenfelder trennen müssen. Allerdings denkt in so einem Moment niemand an solche Zusatzaufgaben. Und nur um Daten genauer abzulegen will niemand all die Oberflächen und Reports anpassen.

Daher bin ich mittlerweile der Meinung dass bei den ersten Anzeichen einer fachlichen Verwendung der technischen Daten die Alarmglocken läuten müssen. Fängt man an bei einzelnen Objekten technische Felder einzublenden ist dies ein deutliches Zeichen das hier ein fachliches Feld fehlt. Der Aufwand dies jetzt gleich sauber zu lösen ist geringer als wenn man wartet bis dieses Feld überall verwendet wird. Und fehlt doch gerade die Zeit kann man immer einen entsprechenden Task eröffnen und im nächsten Sprint (mit zusätzlichen Informationen) beheben.

Dies gilt übrigens im gleichen Masse für fachliche Felder die technisch genutzt werden, auch wenn dieser Fall wohl weniger oft vorkommt.

 

Fazit

Das Single Responsibility Principle (SRP) gilt nicht nur für Klassen und Methoden, sondern auch für Daten. Bevor man für eine kleine Einsparung bei der Datenmenge anfängt Felder mehrmals zu verwenden sollte man sich über die möglichen Konsequenzen bewusst werden und darauf verzichten. Angesichts der aufwändigen Fehlersuche bezweifle ich das durch ein “eingespartes” Feld wirklich Kosten gespart werden können.

Schlagworte: , ,

Buch-Rezension zu “Domain-Driven Design”

3. Februar 2013 1 Kommentar

Domain-Driven DesignWenn man sich mit Behavior Driven Development (BDD) und dem Schreiben von Akzeptanztests beschäftigt stösst man immer wieder auf ein Buch:
Domain-Driven Design: Tackling Complexity in the Heart of Software” von Eric Evans.

Dieses Buch gilt weit herum als Standardwerk das man unbedingt kennen muss. Beim Lesen merkt man schnell das Evans sehr viel Erfahrung hat und weiss wovon er schreibt. Leider macht er dies so ausführlich dass man kaum vorwärts kommt. “Man müsse die Informationen herausschürfen” ist eine Bemerkung über dieses Buch die man beim Lesen im Hinterkopf behalten sollte.

 

Kernpunkte

Von all den Themen die Evans behandelt stechen für mich diese Punkte besonders hervor:

Mit Hilfe einer Ubiquitous Language (einer einzigen gemeinsamen Sprache) sollen alle am Projekt beteiligten Personen kommunizieren. Dadurch das alle die gleichen Begriffe benutzen können Missverständnisse und Übersetzungsprobleme (im Sinne von Fachspezifisch zu Technisch) früh erkannt werden oder entfallen ganz. Auch ist es für Entwickler einfacher sich an die Spezifikationen zu halten wenn die Objekte im Code gleich heissen wie in den Anforderungen und den Testszenarios.

Bei Refactoring denkt man meistens an einen technischen Vorgang um Code besser zu strukturieren. Neben diesem technischen Aspekt gibt es aber auch einen fachlichen. Evens zeigt bei „Refactoring Toward Deeper Insight“ auf wie man nach und nach das Domänenmodell um neue Erkenntnisse verfeinern kann.

Entwickelt man nach Model Driven Design darf das Modell nicht in einem Vakuum erstellt werden. Ist dieses Modell technisch nicht umsetzbar wird in der Entwicklung gezwungenermassen eine Lösung gefunden die davon abweicht. Damit verliert man alle Vorteile und muss ständig zwischen mehreren Modellen hin und her wechseln. Neben höheren Kosten leidet dabei auch die Kommunikation.

Bounded Context: Das eigene Domänenmodell kann noch so gut sein, wenn man es nicht abgrenzt fliessen die unterschiedlichen Konzepte der Umsysteme hinein. Evens zeigt eine ganze Reihe von Ansätzen um dies zu verhindern (wie das Pattern “Anticorruption Layer”).

Software-Entwicklung ist mehr als das Schreiben von Code. Es geht um das Lösen von Problemen. Damit man die passende Lösung finden kann ist eine Zusammenarbeit mit allen beteiligten Parteien nötigt.

 

Kritik

Die gleichen Namen und Bezeichnungen zu verwenden ist ein grosser Schritt in die richtige Richtung. Nur ist es damit nicht getan. Mir fehlt wie man auch zu einer gemeinsamen Bedeutung kommt und überhaupt die Wiedersprüche aufdecken kann. (Wenn alle von Autos sprechen, wie merkt man das der eine einen Golf meint und der anderen einen Ferrari?)

Die ersten beiden Teile sind sehr schwerfällig geschrieben. Immer wieder springt Evans von einer Idee zur nächsten und wieder holt dieses hin und her mehrmals. Würde dies aus unterschiedlichen Perspektiven geschehen wäre dies ein Plus fürs Buch. Leider sucht man die ganze Zeit nach den Unterschieden zum bereits behandelten und findet meist keine. Dies bremst den Lesefluss und schlägt auf die Motivation.

Anstelle der vielen Wiederholungen wären Beispiele zur technischen Umsetzung hilfreich. Statt so viel über Code zu sprechen hätte Evens diesen zeigen können – dies ginge schneller und hätte einen Praxisnutzen. So bleibt zu viel eine schöne Idee ohne Hinweis auf deren Umsetzung.

 

Alternative

Abel Avram und Floyd Marinescu sahen ebenfalls einige Verbesserungsmöglichkeiten und schrieben 2006 das Mini-Book “Domain Driven Design Quickly“. Auf rund 100 Seiten gibt es all die Konzepte aus dem Buch von Evans, ein Interview mit ihm und es hat noch Platz für Ergänzungen aus “Applying DDD” von Jimmy Nilsson.

Wer ins Thema DDD einsteigen will sollte sich erst einmal das PDF bei InfoQ herunterladen.

 

Fazit

Mit Domain-Driven Design wurden viele wichtige Ideen erstmals in Buchform veröffentlicht. Die darin behandelten Themen sind auch heute noch aktuell und ein Umsetzen der von Evens vorgestellten Ansätze würde so manches aktuelle Problem lösen.

Leider verzettelt sich Evans mit seinen Erklärungen und macht es dem Leser äusserst schwer diese Konzepte zu verstehen. Als Einstiegslektüre ins Thema DDD kann ich dieses Buch daher nicht empfehlen. “Domain Driven Design Quickly” ist dafür die bessere Wahl, da die gleichen Konzepte viel besser auf den Punkt gebracht werden.
Kehrt man nach diesem Umweg zu Evens zurück versteht man seine Ideen viel besser und erkennt dann auch was sonst noch alles für Informationen in diesem Buch stecken.

 

Zum Buch

Domain-Driven Design: Tackling Complexity in the Heart of Software” von Eric Evans, 2003 Addison-Wesley, ISBN 978-0-3211-2521-7, 560 Seiten, Englisch

Buch-Rezension zu “Building Enterprise Applications with WPF and the MVVM Pattern”

25. April 2011 3 Kommentare

Building Enterprise Applications with Windows Presentation Foundation and the Model View ViewModel Pattern” von Raffaele Garofolo erschien im März 2011 bei Microsoft Press. Das MVVM Pattern ist für Silverlight und WPF Anwendungen schon fast ein Muss. Für den geringen Betrag von 15$ bekommt man ein gutes Buch zu MVVM.

 

Das Buch startet wie zu erwarten mit einer Einführung ins Model View ViewModel Pattern und dessen Abgrenzung gegenüber den sonstigen UI Patterns wie MVC oder MVP. Mit diesen Grundlagen ist man gerüstet um die einzelnen Schichten einer Anwendung anzuschauen. Vom Domänenmodell geht es über den Data Access Layer durch die Geschäftslogik zur Oberfläche der Anwendung.

Als Abschluss bietet das Buch eine kurze Übersicht zu MVVM Frameworks und Toolkits wie Caliburn, Prism, MVVM Light Toolkit oder Cinch.

Am Ende jedes Kapitels findet man ein grösseres Beispiel in dem die gerade beschriebenen Punkte zu einem realistischen Szenario verbunden werden. Dies sollte man unbedingt anschauen, da der Text im Kapitel selber wohl nicht jedem genügen wird.

 
Klein, aber fein?
Das Buch ist mit nur 224 Seiten recht dünn, behandelt aber dennoch eine grosse Anzahl von Themen. So kann vieles nur angeschnitten werden, für eine Vertiefung fehlt es an Platz. Wer hier eine detaillierte Einführung in Caliburn erwartet muss zwangsläufig enttäuscht werden.

Es gibt aber Themen wie das Repository- oder das Unit of Work Pattern, die mit ausreichendem Tiefgang beschreiben werden. Der Mehrwert dieses Buches liegt für mich beim kombinieren der einzelnen Themen und Ansätze zu einem Gesamtbild.

Im Grossen und Ganzen hätte der Verzicht aufs eine oder andere Toolkit oder Framework dem Buch wohl mehr Profil gegeben. Jetzt wird zwar jeder angesprochen, doch wer eine Empfehlung für ein spezifisches Produkt sucht wird enttäuscht.

 
Test-Driven
Garofolo legt sehr viel Wert auf die Testbarkeit der vorgestellten Ansätze. So findet man neben einer minimalen Einführung in Test Driven Development über das ganze Buch verteilt immer wiederkehrende Beispiele wie man in dieser Situation nun genau den Code testen kann. Diese Hilfestellung fand ich sehr gut und ich wünschte mir, dass mehr Autoren so viel Wert auf die Testbarkeit legen würden.

 
Downloads
Beim Link zu den Code-Beispielen gab es scheinbar einige Probleme. Der Source Code finden sich auf http://examples.oreilly.com/9780735650923-files/9780735650923_files.zip. Man könnte für die Zukunft noch die ReSharper-Dateien und Binaries weglassen, wodurch das Zip deutlich kleiner würde.

 
Fazit
Wer eine kurze und günstige Einführung ins MVVM Pattern sucht wird in diesem Buch das gewünschte finden. Man muss sich aber mit WPF oder Silverlight auskennen, denn dies ist keine Einführung in diese Technologien.

 
Zum Buch
Building Enterprise Applications with Windows Presentation Foundation and the Model View ViewModel Pattern” von Raffaele Garofolo, 2011 Microsoft Press, ISBN Print 978-0-7356-5092-3, ISBN E-Book 978-0-7356-4982-8, 224 Seiten, Englisch

Schlagworte: , , ,

Buch-Rezension zu “Dependency Injection in .Net”

23. Januar 2011 2 Kommentare

“Dependency Injection in .Net” von Mark Seemann erscheint 2011 bei Manning. Man bekommt das Buch aber bereits jetzt via MEAP. Da nur noch ein einziges Kapitel zu Spring.Net fehlt, wage ich mich bereits an eine Rezension.

Schon zu Beginn des Buches wird einem klar, dass man es hier mit etwas speziellem zu tun hat. Welches Buch zu irgendeinem IT-Thema beginnt mit einer Erklärung wie man eine Sauce béarnaise zubereitet? Man mag schon fast meinen Manning hätte die Bücher vertauscht, doch hat diese Einführung durchaus ihren Sinn.

Mark Seemann kocht gerne und sieht zwischen Dependency Injection (DI) und einer Sauce béarnaise parallelen: Bei beiden vermutet man es sei kompliziert und viele verzichten daher darauf. Die ersten Versuche können fehlschlagen, doch hat man mal den dreh raus wird man es überall anwenden können.

 
Klare Struktur
Will einem ein Buch beim Strukturieren der eigenen Programme helfen, so sollte es selber auch klaren Strukturen folgen. Dies gelingt „DI in .Net“ so gut, dass man die einzelnen Kapitel in beliebiger Reihenfolge lesen könnte.

Wer dem vorgegebenen Pfad folgt beginnt mit einer Einführung, lernt Patterns und wie man DI auch von Hand machen kann. Sind einem alle nötigen Abläufe bekannt, zeigt einem der letzte Teil die jeweiligen Vor- und Nachteile dieser DI-Container:

 
Patterns und Anti-Patterns
Im Kapitel zu Patterns werden einem die Anwendungsmöglichkeiten von DI in .Net gezeigt. Seemann bevorzugt ganz klar die Abhängigkeiten wie Konstruktor den Objekten zu übergeben. Geht dies nicht kann man auch über Properties die Werte setzen oder bei jedem Methodenaufruf einen entsprechenden Kontext mitgeben.

Bei jedem Pattern wird immer erst erklärt wie das Prinzip funktioniert. Anhand der .NET Base Class Library (BCL) wird dann gezeigt, wo dies von Microsoft selber umgesetzt wurde. So zeigt Seemann wo man dieses Konzept schon bei der täglichen Arbeit nutzt – ohne das man DI verwendet. Ein ausführliches Beispiel rundet die jeweilige Vorstellung ab.

Bei den Anti-Patterns läuft es ähnlich ab. Nach einer Erklärung was er unter diesem Pattern versteht beschreibt Seemann wieso dies ein Problem ist. Die kleinen Abkürzungen ziehen Probleme mit sich die zwar harmlos aussehen aber zu grossen Verrenkungen führen. Gut gemeint ist halt noch lange nicht gut gemacht – dies gilt auch für die Konzepte rund um DI. Die vorgeschlagenen Refactorings zur Korrektur fand ich sehr hilfreich und sind das Geld fürs Buch bei weitem wert.

 
DI und Manning – war da nicht schon etwas?
Vor ein wenig mehr als einem Jahr habe ich schon ein anderes Buch zu diesem Thema mit dem Titel “Dependency Injection” vorgestellt. Mein Fazit war damals durchzogen und ich schlug vor, auf eine 2. Ausgabe zu warten. “Dependency Injection in .Net” ist zwar nicht diese 2. Ausgabe, aber es erfüllt meine damals erhofften Verbesserungspunkte. Das Buch ist sehr angenehm zu lesen und bekommt die Prinzipien und Vorteile auf eine sehr einfache Art erklärt.

 
Trotz MEAP bereits jetzt kaufen?
In der Mitte Januar vorliegenden Version ist das Buch noch nicht ganz fertig. Laut der Übersichtsseite fehlen noch ein Kapitel, das Vorwort, die Danksagung und der Index. Auch im Layout wird es in den nächsten Monaten noch zahlreiche Änderungen geben. Mir hat das Buch in der aktuellen Form schon sehr geholfen. Mir gefällt es aber auch schon bei der Entstehung Verbesserungen anregen zu können (via Online-Forum).

Wer grossen Wert auf ein perfektes Layout legt, sollte lieber noch bis zur offiziellen Veröffentlichung warten. Diese ist derzeit für den Juni 2011 geplant.

 
Fazit
Das Buch bietet eine gute Einführung ins Thema Dependency Injection. Durch den Aufbau und die vielen Tipps und Tricks ist es auch für Leute geeignet die mehr wollen als nur eine Einführung. Ich kann das Buch daher ohne Einschränkung weiterempfehlen.

Ich gehe sogar soweit dieses Buch als „Must Read“ zu deklarieren. Die darin vorgestellten Konzepte und Ideen sind so grundlegend, das man als Entwickler nicht darum herum kommt.

 
Zum Buch
“Dependency Injection in .Net” von Mark Seemann, 2011 Manning, ISBN 978-1-935182-50-4, >500 Seiten, [Englisch]

Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 278 Followern an