{ Sebastian Jancke, ein Blog }

Am 5. und 6. Juni veranstalten SOPTIM, Die Software Architekten und itemis in Düsseldorf einen Open Space zum Thema "Erprobte Konzepte für Unternehmensanwendungen in .NET".

Der Open Space soll Architekten aus der .NET- und Javawelt zusammen bringen um gemeinsam wachsen zu können. Mehr Informationen und die Anmeldung gibt es unter http://archnet.mixxt.de

Auslöser für die Idee dieser Veranstaltung waren einige gute Gespräche auf dem .NET Open Space 2008 in Leipzig. Dort (und auch sonst) zeigte sich, das eine spezielle Diskussionsplatform für Architektur jenseits der Blaupause nötig ist.

Mehr dazu auch auf Twitter (#archnet09)

namespace Another.Test
{
 public class AnotherFoo
 {
   public string Bar()
   {
     return "Foo: Bar.";
   }
 }
}

Als ich heute diesen Blogpost laß, kam mir unweigerlich folgender Gedanke:

Was hat man uns mit den ASP.NET MVC Beispielen angetan?

Das Problem: Der Titel einer HTML-Seite ist ein Präsentations-Belang der nur durch die View gesteuert und gesetzt werden sollte. Ein Controller sollte nichts darüber wissen. Oren Eini hatte bereits vor einiger Zeit darauf hingewiesen. Aber was nützt es, wenn erst einmal ein schlechtes Beispiel von vielen gelesen worden ist. Da heißt es wohl: dagegen anschreiben.

Ich gebe zu, dies in ersten Tests auch aus den Beispielen übernommen zu haben. Mittlerweile bin ich aber dazu übergegangen, sämtliche vorgeschlagenen Modifikationen umzusetzten. Dies bedeutet, das ViewData.Model passé ist, ViewData der Controller nicht mehr nutzbar ist und Titel durch die View gesetzt werden (durch asp:Content). Somit sind Präsentations- und Kontroll-Belange sauber getrennt und das Modell nur noch streng typisiert verfügbar.

ViewData.Model.SiteMasterViewData.Title

ist jenseits von Clean Code und Lesbarkeit. Letzteres ist es schließlich für mich, was sauberen Code vor allem ausmacht.

Am 26.01.2009 finded das zweite Online Meeting der ALT.NET DE statt (danke Albert!). Albert hat mich gebeten, einen Vortrag zum Thema Domain Driven Design zu halten.

Diesmal habe ich mir überlegt, weniger Focus auf die Patterns (und ihre wörtliche Repräsentation) zu legen und zunächst mehr Raum für offene Fragen und Probleme rund um die Basis (UL, Domänenexperte) zu haben. Anlass waren die letzten Diskussion auf der DDD-Mailingliste in denen klar wurde, das selbst der "Domänenexperte" an sich nicht immer leicht zu identifizieren ist, geschweige denn jeder Zugang dazu hat. Im Anschluss an dieses Fundament möchte ich diskutieren, welchen Rahmen Architektur schaffen muss/sollte/kann um die Arbeit mit und an einem Domänenmodell zu erleichtern.
Als Basis soll ein fiktives (aber für mich aktuelles) Beispiel zum Thema "Order Processing" dienen.

Ich erhoffe mir, dass der Vortrag Anregung zu Fragen und vor allem auch Diskussion des Themas gibt.

Heute morgen las ich in der Süddeutschen Zeitung folgende sehr schöne Formulierung, die in ihrer Wort- und vor allem Namenswahl selten ist:

Dies erinnert mich an den schönen Werbespot von Monster.de, indem Menschen mit sehr langen Beinen die Erd-Rotation mit einer Art Fahrrad sicherstellen ;-)

Zum vierten Mal ein ALT.NET Bier im schönen Köln, diesmal zum Thema Buildmanagement (mit Maven). Stefan, Sergey, Lars und ich hatten dazu Christian Raschka eingeladen. Nach einem kleinen “warm-up” gings ab 19h mit einer Einführung in Maven los. Anschließend diskutierten wir den aktuellen Stand des NPanday-Projektes (früher: NMaven).

Maven ist ein java-basiertes System zum Buildmanagement. Maven ist dabei nur eine sehr kleine Laufzeitumgebung, die erst durch die große Zahl verschiedenster Plugins zum Leben erwacht und arbeitet. Interessant für ALT.NET sind dabei vor allem die Konzeote und Ideen – auch wenn in gemischten Umgebungen ein java-basiertes Buildsystem durchaus pragmatisch erscheint.

Während Ant, NAnt und MSBuild als imperativ aufgefasst werden können, ist Maven rein deklarativ: Man beschreibt was man möchte (Abhängigkeiten, Compiler, Testrunner, Analysen, Reports, …) und Maven kümmert sich um den Rest. Grundsätzlich gilt hier “Convention-over-Configuration”. Es gibt für alles sinnvolle Standardwerte. Zusätzlich sind bestimmte “best practices” als feste Regeln in Maven verbaut. So ist zum Beispiel die Struktur eines Moduls/Projektes immer gleich. Dies hat den Vorteil, dass man darüber nicht mehr nachdenken muss, alle Projekte gleich aussehen und der Standard bereits erprobt ist. Die verschiedenen Bestandteile eines “build” (Phasen!) sind in Maven fest verbaut und entstehen nicht – wie bei Ant – durch das aneinanderreihen von “targets”. Der Vorteil: Eine Phase heißt überall auf der Welt gleich und nicht einmal install, einmal compile und einmal build – hier greifen auch die angesprochenen best practices. Zusätzlich erledigt eine Phase immer die selbe Aufgabe, egal in welchen Projekt (Phasen können trotzdem erweitert werden). 

Eine Assembly (oder in Java: JAR) wird in Maven auch Artefakt genannt. Ein Artefakt kann Abhängigkeiten zu anderen, eigenen Modulen haben oder aber auch externe Abhängigkeiten.

Alle Plugins werden genauso wie Abhängigkeiten zu anderen Modulen aufgefasst: Alles ist eine Abhängigkeit des Buildprozesses. Fehlt ein Plugin oder eine Abhängigkeit, so wird dieses von zentralen Servern (sog. “Repositories”) heruntergeladen. Dort können wiederum weitere (transitive) Abhängigkeiten hinterlegt sein; diese werden dann auch geladen. Alle Artefakte werden in einem lokalen Repository abgelegt, dieses funktioniert also als Cache. Für Unternehmen lohnt sich der Einsatz eines Proxy-Repositories im Unternehmensnetzwerk. Dieser Proxy hat seinen eigenen Cache und versucht Anfragen zunächst daraus zu bedienen. Fehlen hier Artefakte, werden diese über konfigurierbare zentrale Repositories heruntergeladen.

Maven vergibt für erstellte Artefakte automatisch Buildnummern, die sich niemals doppeln können. Grundsätzlich ist jeder Build zunächst als sog. “Snapshot” mit dem jeweiligen System-Benutzernamen markiert. Erst ein spezielles Plugin erzeugt auf Wunsche in komplettes Release. Zur Erzeugung eines solchen gehört dann auch der Upload auf ein angegebenes Repository. Auf öffentlichen zentralen Repositories sind idR keine Snapshots zu finden, dies garantiert die Stabilität der veröffentlichen Versionen. Wer dennoch gegen den “trunk/HEAD” bauen möchte, kann meist Snapshot-Versionen von den Servern der jeweiligen Projekte bekommen. Da Abhängigkeiten mit Versionsnummern definiert werden sollten (oder mit Versionsbereichen), erreicht Maven somit die so wichtige Reproduzierbarkeit von Builds.

Alle beschriebenen Abhängigkeiten eines  Artefakts werdem mit dem Project Object Model (POM) beschrieben. Dazu können auch Angaben über das verwendete SCM (mit Pfad zum Checkout) oder ein Ziel-Repository für Releases gehören. Fehlt der Quellcode kann Maven diesen automatisch aus dem gegebenen SCM herunterladen. Wird ein Release erzeugt, wird zunächst kontrolliert, ob im SCM noch Änderungen vorhanden sind. Falls es solche gibt, werden diese zunächst auch “ausgecheckt”. Anschließend wird der komplette Build durchgeführt und der Stand im SCM getagged. Das fertige Release wird dann ins lokale Repository und in das angegebene Ziel-Repository installiert.

Für .NET gibt es schon länger ein Reihe von Maven-Plugins, um .NET Compiler, Testrunner, Analysen, etc. zu unterstützen. Nach 2 Jahren im Apache Incubator konnte das Projekt aber nicht genügend Geschwindigkeit und Halt in der Community erzeugen. Deshalb ist der aktuelle (funktionierende) Stand nun unter neuem Namen nach Codeplex gewandert. Die Plugin-Sammlung heißt nun NPanday. Damit ist Maven sicherlich näher an .NET gerückt, fraglich ist aber ob der Ansatz einer Java-Runtime beibehalten werden kann. Derzeit scheinen die Pläne vorzusehen, sich noch stärker mit MSBuild im Rücken zu verbinden und langfristig die Java-Abhängigkeit zu verlieren. Auch veröffentlichen derzeit keine der großen Open Source Projekte in der .NET Welt ihre Artefakte auf zentralen Repositories. Für mehr Sichtbarkeit von Maven und die Aufnahme von mehr Geschwindigkeit müssten sicherlich Projekte wie NHibernate, Castle Windsor, Spring.NET, NUnit, xUnit, … sich beteiligen und ein Deployment auf einem zentralen Server pflegen. Dazu müsste man sicherlich “unten” anfangen und die Basis (Unittesting-Frameworks, Castle Dynamic Proxy) zuerst deployen, damit alle darauf aufsetzenden Projekte ihre Abhängigkeiten korrekt definieren können.