Als kleine Checkliste hilft es, die folgenden Bereiche jeweils zu überprüfen. Hierbei werden die typischen Bereiche abgeklopft, die natürlich nicht immer in Betracht gezogen werden müssen oder für jedes Projekt anwendbar ist.

Änderbarkeit kann natürlich auch als Wartbarkeit aufgeführt werden, also die Möglichkeit zur Veränderung und Erweiterung.

Eine kommentierte Liste der Kriterien ist als Exel-Datei angehängt.

Die völlig neue Codebasis wird eventuell auf SWT basiert sein, eine verlässliche Aussage seitens SpringSource gibt es hierzu noch nicht.

Fraglich ist natürlich, was der Vorteil gegenüber der Eclipse RCP oder dem Swing Application Framework ist, die beide schon jetzt verfügbar sind.

1. Codebasis auf Java 1.5, Unterstützung für Java 1.5+
2. Einführung einer Spring Expression Language
3. Unterstützung für REST
4. Validierung mittels Deklaration bzw. Annotation
5. Unterstützung für Portlet 2.0

Spring wird natürlich nach wie vor für Java 1.4.x einsetzbar sein. Um Spring zu bauen wird allerdings Java 1.5+ vorausgesetzt.

Zukünftig wird es voraussichtlich nicht mehr ein spring.jar geben, sondern jedes Modul wird getrennt verfügbar sein, z.B. spring-aop.jar. Ferner werden die Abhängigkeiten nicht mehr mitgeliefert, also spring-with-dependencies.jar. Diese enthielten sowieso nur die Bibliotheken, die zur Ausführung des Beispiels notwendig sind, teilweise fehlen also notwendige Bibliotheken.

In Spring 3.0 wird einiges an Code entfernt werden, zum Beispiel der klassische Support für TopLink, da sich hier eher die Richtung in JPA bewegt. Einiger Code wird als veraltet markiert, wird aber trotzdem noch verfügbar sein, zum Beispiel die Unterstützung für JUnit 3.8, da hier auf JUnit 4.4 umgestellt wurde, sowie die frühen Versionen des Spring MVC.

1. Apply a consistent packing naming convention.
2. No cycles in your logical architecture, no cycles in your layers.
3. No cyclic dependencies between different packages.
4. Keep coupling low.
5. Limit lines of code per file, 700 lines should be the maximum value.
6. Limit cyclomatic complexity of methods, e.g. 15, at least less than 25.
7. Limit the size of packages, e.g. less than 50 types.

Notes on the above

Slice technical stuff horizontally, business stuff vertically. An easy pattern for example is <id>.<project>.<module>.<implementation>, e.g. de.xroot.travel.reservation.dao.hibernate.

Coupling can be measured with ACD (Sum of dependent files for each file). In this case less than 7% for 500 files is good, for 1,000 files it would be better to keep below 4%. Alternative use NCCD, then a factor less than 6 is acceptable.

Coupling can be reduced by using Dependency Inversion, i.e. program against interfaces, and Dependency Injection. Re-use will increase coupling, but that is very good, so a reduction to 1 - a file depends only on itself - is not desirable.

Cylces are evil per definition ;-). All cycles can be broken by using interfaces and eased by abstraction.

Out of the wild

Most projects that adhere to the above rules will be better than 80% of the existing projects. That doesn’t mean that those are not cool or not a success story. Spring does adhere to those rules, and it is thus easy to read. Hibernate on the other hand is … well, it is cool and pretty useful. Just don’t try to understand it.

Vermeide Random, verwende stattdessen SecureRandom

Random ist nicht wirklich zufällig, wenn zwei aufeinanderfolgende Zufallszahlen bekannt sind, können alle weiteren erraten werden. Dumm nur, wenn ein Hacker darauf spekulieren kann …

Vertraue keiner externen Quelle, insbesondere keinen Eingaben des Anwenders

Im einfachsten Fall sprechen wir von Texteingaben, es betrifft aber RSS-Feeds, Emails usw. Nach Analyse von (öffentlichen) Sicherheitsmeldungen konnte ein schlauer Mensch ca. 60% der Fehlfunktionen auf fehlende Überprüfung der Eingabe klassifizieren - vielleicht mag ja jemand mal die Quelle nachreichen. Aus der Erfahrung von Bruce Sams heraus können die meisten Sicherheitsprobleme in Webanwendungen dem Datenfluss zugeordnet werden, genauer der ungenügenden Validierung von Eingaben und anderen externen Quellen. Das deckt sich mit meiner Erfahrung, dass die meisten Probleme in Webanwendungen durch “komische” Eingaben erzeugt werden.

Lösung: Versuche möglichst nicht, die Daten im nachhinein zu validieren, sondern bestimme genau, was zulässig ist, und was nicht. Was an der Oberfläche abgefangen werden kann, sollte da auch abgefangen werden. Vertraue der Oberfläche aber nicht bedingungslos, genau die kann in Webanwendungen manipuliert werden.

Überprüfe Deinen Code

Die offensichtlichsten Probleme im Code lassen sich auch durch statische Analyse finden. Bevor also eine umfassende Datenflussanalyse durchgeführt wird, oder zumindestens ganz wilde Eingabetests, lasse Tools wie FindBugs und JDepend auf den Code los. Ich selber mag z.B. auch Checkstyle sehr gerne.

Ergänze dies durch JUnit-Tests, und zwar mit zufälligen Eingaben, mit Überprüfung der offensichtlichen Grenzbereiche (wie z.B. gar keine Eingabe und überlange Eingabe), sowie mit allen behobenen Fehlerfällen. Wichtig: Jeder behobene Fehler sollte wirklich in einem JUnit-Test landen, sonst kommt er irgendwann einmal wieder.

Why OSGi (Open Services Gateway Initiative) ?

1. Wire components together, not only beans or such
2. Manage these components

What is OSGi?

In this case not the alliance but the specification and the API for a component framework - actually it is a SPI including the test cases. You can feel free and provide your own implementation - the interfaces are all in Java. You might have heard of Equinox as the Eclipse implementation.

What does it have in stock for you?

• Register services (which are basically interfaces)
• Bind implementations to a service
• Find a service (or more precisely the bound implementation)
• Listeners on service binding and unbinding

Component Life Cycle

1. install
2. start
3. stop
4. update
5. uninstall

You can react on any life cycle update and do what you need to do, e.g. allocate a connection pool on install, free it on uninstall, etc.

Kaum ein Vortrag, wo kein Mac OS die Folien beisteuerte, das Verhältnis war gefühlte 60% Apple und 40% Windows.

Interessant aber dass der Apple auch außerhalb der Vortragsnomaden seinen Siegeszug hält, ob in der Lobby oder sonstwo. Nur die Aussteller hatten mehrheitlich auf Windows gesetzt. Nun ja, viele spannende Themen laufen halt auch auf der Kommandozeile ab, vor allen die Skriptsprachen wie Ruby On Rails, Groovy, etc. Und der Apple hat halt neben dem richtig schönen und schnellen grafischen Desktop immer sofort ein Terminal parat.

Übrigens: Auf meinem Rechner läuft auf Kundenwunsch weiterhin Windows XP … man darf doch wohl noch träumen.

Domain Driven Design - Entwurf getrieben von den fachlichen Anforderungen

Warum?

Weil die Fachlichkeit i.d.R. die Aspekte sind, die am längesten stabil bleiben bzw. sich am wenigsten verändern um die sich letztendlich alles dreht. Beispiel: Die Kontonummer eines Kunden hat immer Bestand, egal welche Anwendung darauf zurückgreift. Aus Erfahrung wissen wir auch, dass Daten stabiler als Methoden sind, d.h. Artikel werden seit Jahren immer auf die gleiche Weise abgelegt, egal ob die Zugriffssoftware in COBOL oder Java erstellt wurde.

Was sagen die Vortragenden?

“Einige Dich auf eine Sprache!” - das ist das eigentliche Motto. Domain entspricht hierbei der Fachlichkeit bzw. dem Fachwissen, und zwar explizit nicht der technischen Sicht. Domain Driven heißt hierbei Orientierung am Anwender, also wird alles von der fachlichen Ebene getrieben, nicht von der technischen Umsetzung.

Die Modelle bzw. der Code sollte die Sprache der Fachanwender wiederspiegeln, damit die Anwender direkt mit den Entwicklern sprechen können und ein gemeinsames Verständnis der Begriffe vorhanden ist, auch im Hinblick auf spätere Änderungen und Fluktuationen.

Orientiere Dich in der technischen Umsetzung immer an der Unterstützung der fachlichen Anforderungen, und Deine Codebasis wird stabiler und einfacher sein, sowohl in der Entwicklung als auch in der Wartung, selbst wenn die Anwendung skaliert.

Tipps und Tricks

1. Mache die Domain Objects (Geschäftsobjekte) als auch die Business Logic (Geschäftslogik und -prozesse) explizit, bündele sie und denke an die entsprechende Benennung! Factories, Composites, Strategies helfen hier.
2. Domain Driven Design ist eine notwendige Voraussetzung für Model-Driven Software Development (MDSD), da sonst keine (stabile) formale Spezifikation möglich ist.
3. Domain Driven Design ist hilfreich für Extreme Programming (XP), legt aber mehr Wert auf Dokumentation und kann auch in großen Projekten von großem Nutzen sein.
4. Änderungen im Domain Model (sowie in der Domain) sind teuer, lohnen sich aber immer. Verschleppung ist noch teurer, und zwar exponential.
5. Partionierung der Domains ist ein gutes Mittel, insbesondere um die Kerndomäne herauszuschälen und die logisch Domänen zu trennen und damit beherrschbar zu machen.
6. In großen Projekten muss die Kerndomäne identifiziert werden und kurz und prägnant beschrieben werden, am besten in Form eines “Vision Statements”.

Ach so: Alle Eindrücke und Zusammenfassungen sind höchst subjektiv und nie ein Zitat … so haben die Herren und Damen es vorne garantiert nicht gesagt, so hat der Autor es verstanden und wollte es so verstehen.

Danke für die Nachsicht!