Als Gegensatz dazu gibt es Enterprise Java Next Generation mit Dependency Injection, leichtgewichtigen Containern usw. Dadurch hat man viele Technologien und Frameworks, mit wenig Einschränkungen, vielen Ideen und vielen Freiräumen. Die Technologien sind aber nicht aufeinander abgestimmt (was ich persönlich so nicht glaube), die Best Practivces sind auf einzelne Layers begrenzt und es ist keine Architektur vorgeschrieben.
Also muss man seine eigene Architektur definieren, die eigenen Anforderungen kennen und daraus eine umsetzbare und vermittelbare Architektur bauen. PowerPoint ist keine Architektur, 500 Seiten Word liest niemand und ein Wiki hat keine Struktur. Zutaten für eine Architektur ist Component Based Architectur, SOA - und Performance... Soll man nun eine Architektur technologieneutral definieren? Und wie finde ich raus, ob eine Technologie zur Architektur passt? Und wer schließt die Lücke? Der Architekt, der keine Technologien kennen, oder der Entwickler, der die Technologie nicht versteht?
Also benötigt man einen Super Software Architekt, der die Architektur definiert, Technologien und Ideen verbindet und die Vorgehensweise definiert, Tolls einführt, Coaching und Training durchführt und Begeisterung und Entwicklungskultur etabliert.
Haben verschiedene Architekturen Gemeinsamkeiten? Es geht immer um Divide and Conquer, das Zerlegen großer Herausforderungen in kleinere.
Was sind Komponenten? Spring definiert zum Beispiel welche. Typischerweise haben sie einen Zustand, einen Lebenszyklus, man kann die Abhängigkeiten managen und es gibt gemeinsame Dienste. Also entsteht Zwiebelsoftware mit mehreren Schichten. Eine Alternative sind die Module, mit denen man die Software in einzelne unabhängige Teile aufteilen kann. Die können mehrere "klassische" Schichten umfassen.
Die Module können Abhängigkeiten haben und diese sollten Versionsnummern haben. Die Implementierung der Module kann man hinter Interfaces verstecken, die man dann mocken kann (für Tests zum Beispiel). Und die Abhängigkeiten kann man nach Laufzeit und Compile-Zeit unterscheiden. Außerdem gibt es transitive Abhängigkeiten und dadurch möglicherweise auch unabsichtlich zirkuläre Abhängigkeiten. Die führen dann dazu, dass man im Extremfall das System nicht mehr compilieren kann.
Für die Compile-Time-Abhängigkeiten gibt es dann Maven, für die Runtime-Abhängigkeiten Spring. Das ganze sollte man dann mit Continuous Integration kombinieren, um die aktuellen Sachen auch wirklich zu bauen und den Entwicklern zur Verfügung zu stellen.
Die Subsysteme kann man dann nach technische Infrastruktur, Business Logik und Application Assembly unterscheiden. Man kann dann schon sehr früh Subprojekte nach den technischen Abhängigkeiten strukturieren. Dabei kann man die Technologien in eigene Projekte wie ti-hibernate kapseln. Diese Module enthalten auch eigene Möglichkeiten zur Modularisierung der Konfigurationen.
Er wies dann auf Antidoto, sein eigenes Open-Source-Framework für die Modularisierung auf Basis seiner Ideen. ¶ 13:47
