{ Sebastian Jancke, ein Blog }

Architecture.NET Open Space 2009

noreply@blogger.com (Sebastian Jancke) — Wed, 13 May 2009 14:55:00 +0000

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)

Testing SyntaxHighlighter 2.0

noreply@blogger.com (Sebastian Jancke) — Sun, 08 Feb 2009 16:57:00 +0000

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

ASP.NET MVC: Keine Präsentations-Belange im Controller

noreply@blogger.com (Sebastian Jancke) — Thu, 22 Jan 2009 17:38:00 +0000

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.

Technorati Tags: alt.net,altnetde,readability,asp.net mvc

ALT.NET DE Online Meeting # 2 - DDD

noreply@blogger.com (Sebastian Jancke) — Mon, 12 Jan 2009 12:11:00 +0000

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.

Zum Jahresende: Koordinierte Weltzeit und irdisches Schwanken

noreply@blogger.com (Sebastian Jancke) — Wed, 31 Dec 2008 15:51:00 +0000

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 ;-)

ALT.NET Cologne #4 – Buildmanagement

noreply@blogger.com (Sebastian Jancke) — Tue, 30 Dec 2008 10:53:00 +0000

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.

Technorati Tags: alt.net,altnetde,dotnet

BDD dein MVC

noreply@blogger.com (Sebastian Jancke) — Thu, 11 Dec 2008 23:08:00 +0000

Vor ca. zwei Wochen habe ich mit dem ASP.NET MVC Framework im Rahmen eines verteilten Architektur-Prototypen begonnen. Ich war ich natürlich gespannt, ob sich mit dem MVC Framework auch nach BDD entwickeln lässt. Dies ist schließlich das Versprechen des MVC-Teams: Testbarkeit.

Ich kann sagen, dass nicht zu viel versprochen worden ist. Die Arbeit mit dem MVC Framework und die Erstellung einer Web-UI damit lässt sich problemlos mit Behavior Driven Development durchführen. Nachdem Albert schon einige seiner Erweiterungen vorgestellt hat, möchte ich mich dem anschließen. Davon abgesehen ist dies ein guter Zeitpunkt, einmal Top-Down einen Controller mittels BDD zu entwickeln und damit BDD an einem konkreten Beispiel zu demonstrieren.

Eingesetzte Frameworks

Zunächst einmal ist es wohl fast Pflicht das Projekt MvcContrib herunterzuladen, da es viele “fehlende” Erweiterungen mitbringt. Fehlend ist dabei in Anführungszeichen, weil sich das MVC Framework durch sehr gute Erweiterbarkeit auszeichnet: Factories für Controller, Routen und auch die komplette Render-Engine lassen sich austauschen. MvcContrib bringt eine Reihe von fertigen Implementierungen für IoC-Container (Castle Windsor, Spring.NET, …) und auch Render-Engines (Brails, NHaml, …) mit. Als Render-Engine setzte ich ASP.NET ein, Windsor ist mein IoC Container der Wahl.

Darüber hinaus kommt für Unit- und Integrationstests xUnit mit Björns xUnit.BDDExtensions zum Einsatz.

Entwicklung eines Controllers anhand einer Userstory

Für diesen Artikel habe ich eine Userstory gekürzt: Wenn der Anwender die Webseite “Index” aufruft, soll ihm “alle” gespeicherten Produkte auf der View “Index” angezeigt werden.

Zunächst erstellen wir also eine Specification für diese Userstory. Hier empfiehlt es sich Björns Templates für den Resharper zu installieren. Eine Specification spiegelt immer genau einen Kontext einer Userstory wieder. Diese Specification erzeugt einen ShopController (zunächst ohne weiteren Kontext). Bisher existiert der ShopController nicht. Diesen legen wir dann an. Damit haben wir in unserer Specification vorerst alles arrangiert (der Arrange-Teil von AAA). Wir können die Specification nun ausführen. Nun fügen wir Verhalten hinzu (der Act-Teil von AAA): die Aktion “Index” wird aufgerufen. Diese aufgerufene Methode des System-Under-Test fügen wir nun in die Klasse ShopController ein. Nun kompiliert die Specification wieder und wir können diese wiederum ausführen. Nun ist es an der Zeit, Beobachtungen einzufügen (der Assert-Teil von AAA). Nach der Erstellung einer Beobachtung in der Specification führen wir diese aus (Resultat: Failure, Rot), danach implementieren wir soviel, bis die Specification wieder grün wird. Anschließend fügen wir inkrementell weitere Beobachtungen ein und erfüllen diese wie beschrieben.

Im optimalen Fall beschreibt eine Userstory immer genau einen Kontext, andernfalls müsste diese noch feiner zerlegt werden. Eine Specification entspricht wie bereits gesagt genau einem Kontext, der sich im Namen der Specification samt Beschreibung der Handlung widerspiegelt. Unüblich für C# und Ähnliche ist die Verwendung von Unterstrichen anstelle von Camel Casing. Trotzdem sollte dieser Stil genutzt werden, da er die Lesbarkeit auch in den Testrunnern und Methoden-Übersichten deutlich erhöht.

Bei der Erstellung des Kontext werden auch alle Abhängigkeiten initialisiert. Dabei versteckt die Basisklasse für Specifications die Mechanik (Mocking Framework, …) zur Erzeugung von Abhängigkeiten. Speziell für das MVC Framework habe ich die Basisklasse “ControllerInstanceContextSpecification” angelegt, da diese die Testhelper von MvcContrib versteckt, um einen Controller vollständig zu initialisieren.

Als Beobachtungen sind grundsätzlich Überprüfung des Ergebnisses oder Überprüfung von Methodenaufrufen und Exceptions denkbar. Für Ergebnisse werden diese nach der Handlung in einem privaten Feld der Specification gespeichert (hier: “result”). Für die Überprüfung von Methodenaufrufen und Exceptions ist ein Mocking Framework nötig, das den AAA-Stil unterstützt (zB Rhino.Mocks). Ältere Record-Reply Varianten funktionieren damit nicht. Zur erhöhten Lesbarkeit werden Assertions auf Werten und Methodenaufrufen hinter besser lesbaren Extension-Methods versteckt. Beobachtungen erfüllen somit auch die Forderung, pro “Test” nur eine Assertion auszuführen – andernfalls sind Fehlschläge in Tests schwerer zu lokalisieren.

Der beschriebene Quelltext

Hier nun die komplette Specification:

   1: [Concern(typeof (ShopController))]   2: public class when_a_shop_controller_handles_the_index_action :   3:     ControllerInstanceContextSpecification<ShopController>   4: {   5:     private IDiscService discService;   6:     private ActionResult result;   7:     8:     protected override void EstablishContext()   9:     {  10:         discService = Dependency<IDiscService>();  11:    12:         discService.WhenToldTo(x => x.FindDiscsForSale())  13:             .Return(new List<Disc>  14:                         {  15:                             new Disc(3698, "U2 / All the best",   16:                                      2003,  17:                                      "classical"),  18:                         });  19:     }  20:    21:     protected override ShopController CreateSut()  22:     {  23:         return new ShopController(discService);  24:     }  25:    26:     protected override void Because()  27:     {  28:         result = Sut.Index();  29:     }  30:    31:     [Observation]  32:     public void should_redirect_to_search_view()  33:     {  34:         result.should_be_rendered_view("Index");  35:     }  36:    37:     [Observation]  38:     public void should_retrieve_discs_from_disc_service()  39:     {  40:         discService.AssertWasCalled(x => x.FindDiscsForSale());  41:     }  42: }

Die Implementierung des Controllers sieht dann wie folgt aus:

   1: [HandleError]   2: public class ShopController : Controller   3: {   4:     private readonly IDiscService service;   5:     6:     public ShopController(IDiscService service)   7:     {   8:         this.service = service;   9:     }  10:    11:     public ActionResult Index()  12:     {  13:         /* ...  14:         */  15:    16:         var model = new ShopViewModel();  17:         model.Discs = service.FindDiscsForSale();  18:         return View("Index", model);  19:      }  20: }

Zu guter letzt ist noch die neue Basisklasse für Instance-Specifications nötig. Diese ist speziell für Controller des MVC Frameworks und versteckt die Mechanik der Testhelper von MvcContrib bei der Initialisierung eines Controllers.

   1: public abstract class ControllerInstanceContextSpecification<T> : InstanceContextSpecification<T>   2:     where T : Controller   3: {   4:     protected override void InitializeSystemUnderTest()   5:     {   6:         base.InitializeSystemUnderTest();   7:         new TestControllerBuilder().InitializeController(Sut);   8:     }   9: }

Technorati Tags: alt.net,altnetde,bdd,dotnet,tdd,asp.net

.NET Open Space 2008 rekapituliert

noreply@blogger.com (Sebastian Jancke) — Sun, 02 Nov 2008 17:33:00 +0000

Mit ganz viel Verspätung kommt nun also meine Zusammenfassung des .NET Open Space 2008 in Leipzig. Zunächst ist zu sagen, dass Leipzig wirklich eine schöne Stadt ist. Dank eines ortskundigen Teilnehmers konnten wir am Freitag einige tolle Ecken von Leipzig besichtigen (Auerbachs Keller war natürlich ein Muss). Die Party am Freitag Abend war eine angenehme, lustige Runde zum Kennenlernen.

Der Samstag startete dann mit einer Erklärung des Open Space Konzeptes durch Stefan und der anschließenden Planung der Sessions. Der Versuch, demokratisch jedem Wunsch (und jeder Kollisions-Vermeidung) bei den Sessions beizukommen stellte sich im Laufe des Tages noch als Problem heraus – es dauerte einfach zu lange.

Die erste Session zum Thema “Testen, Test-First, Testbarkeit” interessierte anscheinend fast alle Teilnehmer. Dies führte schnell zur Wandlung in eine (sehr gute) Einstiegs-Veranstaltung und schließlich dann auf die Frage:

Wie verkaufe ich das ans Management?

Dank Björn und Gabriel kam die Diskussion von TDD schnell zu BDD.

Die zweite Session des Tages (die ich besuchte) war ein großer Pool von xDDs: “DDD, BDD, FDD, MDD, MDA, MDSD”. Abgesehen von der Tatsache, dass die Session einfach zu viele Themen gruppierte, gab es zunächst eine Einführung in einige der genannten xDDs. Leider kam die Diskussion zu “xDD – Wieviel wovon?”, die Lars und ich uns gewünscht hätten, nicht zum Zuge. Dafür gab es schnell mal wieder die Frage

Wie verkaufe ich das ans Management?

Überhaupt schien dies für manche ein zentraler Aspekt der Konferenz (oder ihrer Probleme) zu sein: Wie lassen sich aktuelle Entwicklungsmethoden, Ansätze, Philosophien verkaufen? Manch einer soll über TDD auch sagen, dass es einfach zur Professionalität eines jeden Entwicklers gehört, maschinell überprüfbare Tests zu schreiben… Ich hätte gedacht, dass die treibenden Kräfte hinter dieser Dauer-Frage sich schließlich doch zu einer separaten Session treffen, um dies ausführlich zu diskutieren – leider kam es dazu nicht. Somit blieb die Frage weiterhin immer offen im Raum herumschwirren.

Open Space wird auch die organisierte Kaffeepause genannt. Und in den Pausen von dieser organisierten Pause ergaben sich dann einige sehr Interessante Diskussionen unter anderem mit Lars und Björn über Architektur aus der ALT.NET-Sicht und “Von Java lernen”.

In der letzten Session, die ich am Samstag besuchte, war das Thema “ORMs – NHibernate vs LLBLGen”. Es stellte sich schnell heraus, dass hier datenzentrische auf objektzentrische Entwickler trafen, und die wahl der Tools davon maßgeblich geprägt ist. Heftig diskutiert war auch die Frage nach der Einstiegsschwelle von NHibernate. Einige Ehrfahrungsberichte brachten dann doch nahe, dass die grunsätzliche Schwelle niedrig ist – komplizierte Szenarien aber einfach von ihrer Natur her kompliziert sind.

Der erste Tag zeigte, dass die Organisation der Konferenz super, ja (fast) perfekt war. Das Konzept funktionierte wunderbar. Zu meiner Überraschung war das mehrheitliche Interesse doch im Themenbereich ALT.NET angesiedelt (neben den Bereichen Mobile und Softskills).

Am Abend setzten sich die Diskussionen in kleineren Runden auf der Party fort.

Der Sonntag stand zunächst ganz im Zeichen einer schnelleren Session-Aufteilung (Continuous Improvement !) und einer Live-Coding Session zur Demonstration von BDD und Pairprogramming. Diese wurde von Björn und Gabriel durchgeführt. Für mich zeigte sich wieder einmal, dass BDD unschlagbar gut zu vermitteln ist - im Gegensatz zu reinem, alten TDD. Auch die Art der Präsentation (Pairprogramming), wie sie bereits von JP Boodhoo in Bonn demonstriert wurde, scheint einfach gut zu funktionieren.

Später kam es dann zur ersehnten Session zum Thema “ALT.NET Architektur – Von Java Lernen”. Diskutiert wurden zunächst ein typischen Szenario einer verteilten Anwendung. Das Szenario waren drei typische Services für Warenkorb, Kundenmanagement und Bestellungsbearbeitung. Anschließend stellte ein Teilnehmer seine .NET Architektur vor und ich habe mit Lars die gängigen Konzepte im Java Enterprise Bereich und auf Java Application Servern vorgestellt. Offenkundig war die starke Tendenz, Skalierbarkeit in der Performanz durch Asynchronität und Messaging zu realisieren.

Als Ergebnis der Diskussion würde ich sehen, dass wir im ALT.NET Umfeld gerade erst noch am Anfang der Diskussion stehen. Eigentlich bauen alle irgendwie Enterprise Architekturen in .NET, nur scheint kaum jemand darüber zu sprechen (und die MS Guidelines sind von 2005…), gerade über komplexere Themen wie Skalierbarkeit, Sicherheit, … Wir können und müssen wohl noch einiges vom Java Enterprise Bereich lernen. Mehr dazu demnächst…

Technorati Tags: netos2008,alt.net

.NET Open Space 2008, Twitter

noreply@blogger.com (Sebastian Jancke) — Thu, 16 Oct 2008 17:30:00 +0000

Morgen geht’s los zum .NET Open Space 2008 in Leipzig. Wer mir folgen möchte, kann dies nun auch auf Twitter tun:

http://www.twitter.com/sjancke

Ich bemühe mich das ganze dort (und hier) zu dokumentieren – wir werden sehen ob’s klappt.

DDD – Vortrag in Köln (UPDATE)

noreply@blogger.com (Sebastian Jancke) — Mon, 06 Oct 2008 20:00:00 +0000

Hallo,

kurzfristig hat sich der Ort der Veranstaltung geändert. Die DNUG trifft sich morgen (07. Oktober 2008), 19h nun hier:

Grünfeld an der Brüsseler Straße 47.

Siehe dazu auch diese von Albert erstellte Karte.

DDD – Vortrag bei DNUG Köln, 07-10-2008

noreply@blogger.com (Sebastian Jancke) — Mon, 15 Sep 2008 21:29:00 +0000

Wie Albert schon angekündigt hat, gebe ich am 07. Oktober 2008 einen Vortrag zum Thema Domain Driven Design in der DNUG Köln.

Allgemein ist die Konstruktion von Modellen ein effektives Mittel, um die Komplexität eines Problems zu beherrschen. Domain Driven Design setzt als Basis unserer Entwicklungsprozesse die Fokussierung auf die Domäne und ihre Modelle, uneingeschränkt durch technische Komplexität, die heutige Projekte meist überlädt. Das wichtigste Werkzeug ist dabei die allgegenwärtige Sprache als Modell der Domäne und der Kontext, in dem sich das Modell einer Domäne befindet.

Der Vortrag gibt eine Einführung in das Thema und einen Überblick über fortgeschrittenere Techniken:

Voraussetzungen
Allgegenwärtige Sprache
Grundlegende Bausteine als Basis der Sprache und Orientierungshilfe
Modelle reichhaltiger gestalten
Modelle durch ihren Kontext trennen und integrieren
DDD in der Praxis: gängige Probleme und häufige Fragen

Technorati Tags: ddd,domain driven design

Aspektorientierung – der natürliche nächste Schritt

noreply@blogger.com (Sebastian Jancke) — Tue, 02 Sep 2008 16:58:00 +0000

Angefangen hat Aspektorientierug mit Gregor Kiczales und seinem damaligen Forschuntsteam bei Xerox PARC. Seine Arbeit an “Metaobject Protocols” führte zur Erkenntnis, dass vor allem die Modularisierung von sog. “cross-cutting concerns” die größte Verbesserung brachte. Bei Xerox entstand dann AspectJ (welches heute ein Projekt im Eclipse-Bereich ist). AspectJ ist derzeit wohl die am meisten verbreitete AO-Sprache und vielleicht die einzige die wirklich in Produktion eingesetzt wird. Daneben existieren eine vielzahl von AO-Ansätzen durch Container wie das Spring-Framework oder Enterprise Java Beans (EJB), die eine weite Verbreitung gefunden haben und einer großen Zahl von Entwicklern einen einfachen Zugang zu AO-Technologie bieten. Um zu verstehen, warum der Schritt zu Aspektorientierung natürlich und logisch ist, müssen wir zunächst verstehen, was treibende Kraft in der Weiterentwicklung der verschiedenen Paradigmen ist.

1974 war es Edsger W. Dijkstra, der in seinem Artikel “On the role of scientific thought” den Begriff “separation of concerns” prägte:

Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one's subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects.

[..] But nothing is gained --on the contrary!-- by tackling these various aspects simultaneously. It is what I sometimes have called "the separation of concerns", which, even if not perfectly possible, is yet the only available technique for effective ordering of one's thoughts, that I know of. This is what I mean by "focussing one's attention upon some aspect": it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect's point of view, the other is irrelevant.

(30th August 1974, Prof. Edsger W. Dijkstra)

Dijkstra argumentierte, das wissenschaftliches Denken in der Entwicklung von Programmen fehlte, jedoch nötig sei um gute, fehlerfreie Programme zu konstruieren. Spätestens seit der erneuten Definition durch Chris Reade in seinem Buch “Elements of Functional Programming” gilt die Trennung der Anliegen als nötig, um die Komplexität eines Systems in den Griff zu bekommen. Die “Separation of concerns” kann als Geisteshaltung hinter dem Ziel der Modularisierung betrachtet werden. Damit ist aber noch nicht geklärt, was genau ein “concern” denn genau ist. Man könnte einen concern als jede Anforderung und jedes Anliegen an eine Software definieren, und dies scheint die anerkannte Definition zu sein. Dabei kann ein concern so generell wie “Interaktion mit einer Datenbank” sein, aber eben auch eine spezielle Berechnung detailliert vorgeben.

Vor dem Problemen der nötigen Modularisierung stehen wir aber nicht alleine. Andere Branchen haben es auf ihre eigene Art gelöst. Architekten scheinen separate Pläne für Wasserversorgung, Stromleitungen, Abflüsse, Lichtinstallationen und natürlich die Konstruktion an sich anzufertigen. Darüber hinaus ist die Innenarchitektur ein ganz eigenständiger Beruf.

Modularisierung ist auf der einen Seite zwingend notwendig, um die Komplexität heutiger Anforderungen in Teile zu zerlegen und so zu reduzieren, damit ist jedoch unklar, wie weit wir die Modularisierung treiben müssen. Die Professorin Carliss Y. Baldwin von der Universität Harvard hat die Modularisierung von einem ökonomischen Blickpunkt aus untersucht und kam zu dem Schluss, dass Modularisierung eine treibende ökonomische Kraft ist, die ganze Märkte (zB den PC-Markt seit Einführung des modularisierten IBM-kompatiblen PCs) umkrempeln kann. Darüber hinaus hat sie auch die Modularisierung mittels Aspekten und den Optionswert von Aspekten untersucht und war Keynote-Speakerin bei der Konferenz AOSD 06. Interessant finde ich an dieser Stelle, dass auch Kent Beck bei seinem Plädoyer für möglichst späte Entscheidungen im eXtreme Programming mit Optionswerten argumentiert hat.

Alle Paradigmen, die bisher zu Felde geführt wurden, von der Strukturierten Programmierung über Prozedurale, Funktionale bis hin zur Objektorientierten Programmierung hatten ein Ziel: bessere Modularisierung. Dabei hat jedes Paradigma seine eigenen Konzepte, ein Modul abzubilden (…, Funktionen, Objekte) kreiert. Dabei wurde jedoch eine Gruppe von Anliegen stets ausgeschlossen, weil sie bei der Dekomposition in Module dieser Paradigmen über Module hinweg verstreut waren und und somit faktisch unsichtbar wurden. Die genannten Paradigmen sind nicht im Stande, diese Gruppe von Anliegen selbst zu modularisieren. Der Grund dafür ist die einfache Tatsache, dass es immer zu einer Zahl von Anliegen einige Anliegen gibt, die andere kreuzen (darauf komme ich noch zurück).

Ich denke es ist klar, dass ich auf cross-cutting concerns hinaus will. Zu oft ist aber versucht worden AO zu verkaufen und dabei die “Neuen” mit einer Reihe von Fachbegriffen zu überladen. Da es sich bei der Aspektorientierung um einen völligen Paradigma-Wechsel handelt (der dennoch rückwärts kompatibel ist), halte ich es für eine gute Idee, vorerst auf genau diese Fachwörter ("buzzwords” ?) zu verzichten. Ich denke dieser Ansatz wird auch durch die Aussage von Gregor Kiczales gestützt, dass die Geisteshaltung von Aspektorientierung weitaus wichtiger ist, als die derzeitigen technischen Umsetzungen und ihre spezielle Ausprägung der Fachbegriffe. Würde man diese nutzen wollen, so müsste zunächst ihre allgemeine Semantik erklärt werden. Dies wird fast nie getan und erscheint für eine Einführung auch zu fortgeschritten.

Im Jahre 2004 stellte Ted Neward, bei einer Podiumsdiskussion zum Thema AOP auf der Konferenz “The Server Side Symposium”, eine Aufgabe: Aspektorientierung zu erklären, ohne die gängigen “buzzwords” zu verwenden. Der Projektleiter des AspectJ-Projektes, Adrian Colyer (heute auch für SpringSource tätig) antwortete mit seinem Artikel “The Ted Neward Challenge (AOP without the buzzwords)”. Seine Argumentation basiert auf der Annahme, dass eine echte Trennung der Anliegen nur erreicht werden kann, wenn das Verhältnis von Konzepten zu Implementierungen genau 1:1 ist, also ein Konzept an genau einer Stelle in der Software Implementiert ist.

Nehmen wir uns ein einfaches Problem (welches auch von Gregor Kiczales untersucht wurde): Eine Zeichentafel (Canvas) und eine Vielzahl verschiedener geometrischer Objekte (Shapes). Die verschiedenen Shapes (Dreieck, Viereck, Kreis, Oktaeder, …) verwalten ihre Eigenschaften und ihr Zeichenverhalten selbst. Wir modellieren sie als Objekte. Ebenso den Canvas. Ein weiteres Anliegen ist auch die Benachrichtigung des Canvas, wenn ein Shape sich verändert. Im Allgemeinen würde man dieses Anliegen durch eine Subject-Observer Beziehung zwischen Canvas und den verschiedenen Shape-Objekten implementieren. Bei allen Änderungen benachrichtigen die verschiedenen Shape-Objekte den Canvas. Das Anliegen der Benachrichtigung ist damit aber nicht mehr eigenständig modularisiert, denn alle verschiedenen Objekte (oder Klassen von Objekten) implementieren die Benachrichtigung auf ihre eigene Art. Wir haben also ein Verhältnis Konzept : Implementierung von 1 : n. Umgekehrt haben wir in einem Objekt nun mehr als ein Konzept implementiert und haben hier ein Verhältnis Konzept : Implementierung von n : 1. Die Krux liegt darin, dass wir schon bei einem sehr einfachen Beispiel ein Anliegen nicht mehr richtig Modularisieren konnten, weil es ein übergreifendes Anliegen ist. Skaliert man das Beispiel auf ein durchschnittlich großes System, ist die ganze Problematik daran vorstellbar.

Nun ließe sich erwidern, dass vielleicht eine andere Art der Dekomposition das Problem gelöst hätte. Dies ist in der Forschung untersucht worden und derzeitiger Stand ist anscheinend, dass es nicht möglich ist. Das Problem wird “Tyranny of the dominant decomposition” genannt. Dies möchte ich anhand eines Beispieles illustrieren: Es soll eine Zeit gegeben haben, in der wir statt MP3s jede Menge CDs im Regal stehen hatten. Wir wollen aus den CDs schnell einige zu einem speziellen Genre suchen. Dazu könnten wir sie nach Genre sortieren. Allerdings würden wir auch gerne schnell CDs nach einem Namen suchen. Vielleicht wäre es also besser, die CDs nach Namen zu sortieren. Dann könnten wir aber nicht mehr schnell nach Genre ähnliche CDs suchen. Die Lösung scheint greifbar: wir sortieren nach Genre und jedes Genre wiederum nach Namen. Damit gehen wir den Kompromiss ein, dass wir nicht sehr schnell nach Namen suchen können, aber wir können sehr gut nach Genre suchen, selbst wenn wir zunächst eine spezielle CD gesucht haben. Das Anliegen “Genre” ist also hier die dominante Dekomposition über dem Anliegen “Namen” (verkürzt gesagt). Kommt nun aber noch das Anliegen hinzu, CDs zu einem Jahr zu finden, haben wir ein Problem, egal welche Dekomposition wir als dominant wählen. Es gibt also nur einen Ausweg: wir müssten sowohl die Suche nach Genre, als auch die Suche nach Namen und auch die Suche nach Jahren eigenständig Modularisieren. Dies scheint mit den Mitteln Plazierung der CDs im Regal nicht möglich, wir brauchen also einen Paradigma-Wechsel.

Das Beispiel der CD-Sortierung zeigt nicht nur die Existenz von übergreifenden Anliegen aus der Problemdomäne heraus. Das Beispiel zeigt vor allem im Gegensatz zum Zeichenbrett, dass übergreifende Anliegen “mehrdimensional” sind und die Zahl der Dimensionen “unbegrenzt” sein kann. Diesem Umstand hat auch IBM mit der Forschung im HyperJ-Projekt Rechnung getragen.

Für Viele ist dennoch Aspektorientierung derzeit vor allem eines: Aspektorientierte Programmierung (AOP), mit einem starken Hang eine Sache Namens “Logging” besonders schön zu lösen. Dabei ist der eigentliche Witz am “Hello world”-Beispiel der AOP die Tatsache, dass dort Tracing modularisiert wird. Innerhalb von Experimenten beobachtet wurde, das in vielen Fällen richtiges Logging – die Präsentation von Debug und Context-Informationen – eigentlich kein cross-cutting concern ist, weil für jeden Context die Anforderungen völlig unterschiedlich sind. Eine Ausnahme bildet vielleicht die einheitliche Protokollierung von Fehlern im System. Darüber hinaus scheint für Viele die Formel cross-cutting = nicht-funktional zu gelten. Das auch diese Reduktion der Aspektorientierung zu kurz greift, zeigt die Tatsache, dass erfahrene AO-Experten in der Regel den wahren Wert von AO bei funktionalen, zur Domäne gehörigen cross-cutting concerns sehen. Nicht zuletzt, weil nicht-funktionale, Infrastruktur-Anliegen heute von Containern (EJB, Spring, …) hinreichend gut modularisiert wurden. Gleichzeitig scheint mir hierher die Popularität der (falschen) Formel cross-cutting = nicht-funtional zu kommen. Eben weil die obigen Beispiele mit dem Zeichenbrett oder der CD-Sortierung keinerlei nicht-funktionale Anliegen enthält, mag ich diese besonders. Sie zeigen zum einen, dass bereits sehr simple Domänen cross-cutting concerns enthalten. Zum anderen ist aber auch sichtbar, dass diese meist aus der Problemdomäne entstammen und (gefühlt) die “kleine” Zahl der nicht-funktionalen Infrastruktur Anliegen übersteigt.

Heute, ca. 10 Jahre nach der “Erfindung” der AO ist die Aspektorientierte Programmierung weitgehend stabil und wird produktiv eingesetzt (zumindest im Falle von AspectJ). Forschung findet natürlich auch noch hier statt, scheint sich aber derzeit vor allem auf die Auswirkungen von AO im Bereich des Software Engineerings zu konzentrieren: Requirements Engineering, Refactoring, Patterns, Productlines, Tooling und nicht zuletzt “Aspect Mining”. Diese Bereich bieten trotz akuter Forschung trotzdem bereits nutzbare Ergebnisse, die auch Anwendung zu scheinen finden. So gibt es einige nützliche Ergebnisse, bei der Anwendung von AspectJ zur Implementierung von Objektorientierten Patterns in einer Pattern-Library. Die Erweiterung von Use-Cases hin zu sog. “Use-Case slices” und die damit einhergehende 1:1 Implementierung der Kern-Usecases durch Objekte und der Varianten/Extension Points und anderen Usecases durch Aspekte ist sogar als Buch verfügbar. Hier können auch einfache Angriffspunkte zur Feature-Konfiguration im Sinne von Productlines gesetzt werden.

Für “Joe Developer” (Zitat aus dem se-radio.net) scheinen aber viele dieser Techniken/Prozesse/Tools und Ergebnisse im Zusammenhang mit AO bisher unsichtbar gewesen zu sein. Um so mehr ist es an der Zeit, diese Dinge genau zu Beleuchten und statt AspectJ-Tracing-Tutorials lieber “Best practices” und mögliche Einsatzgebiete zu benennen. Den Syntax einer Sprache oder die Details einer Technologie lassen sich schließlich gut aus Büchern und Dokumentation entnehmen. Die Einsatzmöglichkeiten und gute Vorgehensweisen einer Technologie entstammen aber der Erfahrung und dem Umgang damit. Sie können eigentlich nur von den bereits Erfahrenen vermittelt werden, oder aber durch viele Experimente (und Fehlschläge) selbst erlernt werden. Dabei bevorzuge ich eindeutig den ersten Weg und versuche von den Experten zu lernen.

Im Interview von Gregor Kiczales durch Markus Völter (auf se-radio.net) spekulierten schließlich beide darüber, dass zur Annahme des OO-Paradigmas 20 Jahre nötig waren, die Annahme von AO aber bereits nach 10 Jahren sehr weit fortgeschritten ist und die Zukunft positiv aussieht. Nicht zuletzt kommen wohl die meisten heute schon damit in Kontakt, wenn sie Middleware-Plattformen wie EJB-Container oder das Spring-Framework einsetzten.

Zum Schluss möchte ich noch darauf zu sprechen kommen, dass ich bisher nur für Aspektorientierung plädiert habe, nicht aber für den Einsatz einer speziellen AOP-Technologie. Auch habe ich weder nur für AO-Sprachen noch gegen Container-AOP (Spring.AOP, Method interception, …) plädiert. Solche Entscheidungen sind schließlich nicht allgemein entscheidbar, da sie immer von den speziellen Anforderungen, Budgets, etc.. abhängen. Auch die Frage, wie fein Aspekte granuliert werden sollen steht im Raum und beeinflusst insbesondere den Einsatz von “Method interception”, Spring.AOP, AspectJ oder auch eine Kombination dieser. Der Grad der technischen Umsetzung und Einsatz von AO-Technologie ist nicht zuletzt auch durch die “Adoption strategy” gesteuert. Hierzu gibt es wiederum allgemeine Empfehlungen, auf die ich aber ein anderes Mal eingehen möchte und werde.

Nachtrag: Ich habe gestern gesehen, dass Stefan Lieser die Thematik “Tyranny of the dominant decomposition” an einem anderen, aber ebenso schönen Beispiel erläutert hat: Ein Dokument mit Elementen (Text, Absätze, …) und dazu orthogonal die Frage der Formatierung.

Technorati Tags: aosd,aop

Was ist Domain Driven Design?

noreply@blogger.com (Sebastian Jancke) — Sun, 31 Aug 2008 16:51:00 +0000

Bisher in dieser Serie:
DDD – Eine Einführung,
DDD – Allgegenwärtige / Universelle Sprache

In meinem Artikel “DDD – Eine Einführung” hatte ich versucht einen Überblick über Domain Driven Design und seine Auswirkungen zu geben. Leider fehlte dabei eine genaue Definition. Dies ist allerdings nicht einfach und ich bezweifle, ob es derzeit eine komplette und exakte Definition von DDD gibt. Die Beschreibungen auf Wikipedia scheinen mir unvollständig, da sie zu sehr auf den Aspekt des Objekt-Design abzielen. Auch im Buch selbst wird eher schwammig in das Thema eingeführt: Man bekommt schnell ein Gefühl für DDD und, mit Blick auf das Inhaltsverzeichnis, auch für den Umfang. Trotzdem fehlt eine präzise, umfassende Definition. Daher ist dieser Artikel sicherlich zunächst nur ein Versuch – ich maße mir keine Vollständigkeit an.

Der Grund dafür liegt, meiner Meinung nach, in der Tatsache begründet, dass DDD eigentlich vor allem eines ist: ein philosophischer Ansatz, wie Problemdomänen in Software implementiert werden sollten:

Das Modell, und damit die Domäne, sind im Herzen unserer Software

Und "drumherum" bildet DDD damit eine Entwurfsmuster-Sprache, die uns ermöglicht darüber zu kommunizieren. Dies würde ich als eine Definition von Domain Driven Design und dessen Kern bezeichnen wollen (siehe auch David Laribee's Artikel dazu).

Worin liegt dies begründet und welche Auswirkungen hat dieser Ansatz für uns? Gehen wir also zurück zum Anfang. Zunächst dreht sich bei der Erstellung von Software alles um Modelle und Abstraktionen. Haben wir eine gegebene Domäne, so bauen wir zu einer Teilmenge daraus ein Modell, eine Abstraktion der Domäne. Die gesamte Domäne (wie eigentlich alles auf der Welt) ist natürlich zu groß, um sie vollständig zu modellieren. Wenn wir Software entwickeln, bauen wir also primär ein Modell einer Domäne.

Derzeit besteht unsere bester Weg zu Modularisierung und Abstraktion in der Nutzung von Objekt Orientierung. Damit liegt die Idee nahe, unser Modelle durch “nakte” Objekte zu implementieren - wie wir es in der Uni gelernt haben bevor wir über Datenbanken, Transaktionen und Infrastruktur nachdachten. Idealer weise gibt es zwischen Quelltext und Modell keine Unterschiede, also keine Übersetzungen. Im Artikel “DDD – Allgegenwärtige / Universelle Sprache” bin ich bereits darauf eingegangen, warum Eric Evans Übersetzungen als kritisch ansieht. Unser Modell ist also von der Domäne gesteuert.

Wenn wir nun ein Modell der Domäne erstellen, ergibt sich direkt die Frage: Wer kennt die Domäne? Die Architekten? Oder Software Analysten? Oder Entwickler? Wohl kaum. Erstere denken wohl eher an Entwicklung im großen Rahmen, letztere im sehr kleinen und Software-Analysten können wohl analysieren, aber kennen wohl nicht jede Problem-Domäne. Diejenigen, die eine Domäne am besten kennen sind aber direkt vor unseren Nasen: Der Kunde und seine Experten. Diese Idee sehen wir auch in anderen Bereichen, zB in den Agilen Prozessen. Im eXtreme Programming heißt das ganze “Customer On Site”. Da das Modell also keine verborgene Magie innerhalb der Software ist, sondern eine – für alle sichtbare – Abstraktion, ergibt sich die Grundlage des Domain Driven Design:

Das Modell, und damit die Domäne, sind im Herzen unserer Software

Dies hat weitreichende Konsequenzen auf alle Bereiche, wie Anforderungen an die Architektur, Auswirkungen auf Objekt-Design, das Team, seine Prozesse, etc. Weil wir zum Beispiel dieses Modell kommunizieren müssen, sowohl intern als auch extern, liegt die Idee nahe, eine gemeinsame Sprache in allen Beriechen zu nutzen: angefangen bei der Kommunikation, über Dokumentation, Diagrammen bis hin zum Quelltext. Ideal ist es also, wenn sich die Sprache und damit das Modell im Quelltext manifestiert. Dann könnte man nur durch das Lesen des Quelltextes im Domänen-Modul eine Menge über die Domäne selbst lernen.

Zusammenfassend kann man also sagen, dass Domain Driven Design ein Ansatz zur Software-Entwicklung ist, der das Modell einer Problemdomäne ins Zentrum stellt. Kritik und Erweiterungen sind willkommen!

Nachtrag: Definitions-Absatz erweitert um die Idee der Pattern-Language.

Technorati Tags: domain driven design,ddd

Komplexität in Geschäftslogik

noreply@blogger.com (Sebastian Jancke) — Sun, 31 Aug 2008 16:41:00 +0000

Ein Vergleich der Patterns Table Module (DataSets,..), Transaction Scripts und Domain Model

Abseits meiner Beiträge zum Thema Domain Driven Design möchte ich hier die drei Ansätze zur Handhabung von Komplexität in Geschäftslogik aus Martin Fowler’s Buch “Patterns of Enterprise Application Architecture” vergleichen. Alle drei stellen Wege dar, eine Domäne zu modellieren, wenn auch die beiden ersten Ansätze stark zu prozeduraler Programmierung tendieren:

Table Module Pattern (auch bekannt als DataSets in .NET)
Transaction Scripts
Domain Model Pattern

Fowler hat zum Vergleich eine ähnliche Grafik wie die folgende verwendet.

In der Grafik ist Komplexität gegenüber Aufwand gestellt. Die rote Linie steht für das Table Module Pattern, die blaue Linie steht für Transaction Scripts und die grüne Linie steht für das Domain Model Pattern. Die Idee der Grafik ist es zu zeigen, wie die drei Ansätze mit erhöhter Komplexität skalieren. Dabei kommt es nicht so sehr auf den exakten Verlauf an. Wichtiger ist es zu sehen, dass die Grafik recht gut dem gefühlten “Aufwand” entspricht, bei der Arbeit mit den Ansätzen: der Aufwand bei Transactions Scripts und Table Module (in .NET also DataSets) steigt rasant und macht zunehmende Komplexität kaum noch handhabbar. Aber auch das Domain Model Pattern lässt sich nicht unendlich lange nutzen, ohne ans eine Grenzen zu stoßen. Trotzdem liegt diese Grenze bedeutend höher, was das Pattern so attraktiv für komplexe Domänen macht. Zu große Komplexität kann durch Zerteilen der Domäne in verschiedene Modelle begegnet werden. Diese müssen dann aber genau abgegrenzt und integriert werden müssen – andernfalls wird man weniger Nutzen davon haben. Die passenden Stichwörter wären hier Bounded Context, Context Map und Core Domain [/End buzzword dropping].

Die Große Frage am Vergleich der 3 Ansätze ist natürlich: Wo liegen die Grenzen auf der Achse der Komplexität? Dazu müssten wir aber zunächst einmal Komplexität messen – dies können wir aber kaum. Pragmatisch gesehen muss hier die Erfahrung des Teams herhalten. Praktisch gesehen lohnt sich ein Domain Model sicherlich nicht für eine reine CRUD-Anwendung mit nur sehr simpler Validierung. Trotzdem greift wohl auch diese Einordnung zu kurz. Niemand kann schließlich genau vorhersagen, wie sich das Geschäft des Kunden weiterentwickelt oder ob aus einer kleinen Anwendung nicht plötzlich eine große wird – dafür scheinen zu viele “Prototypen” bisher immer noch am Leben. Es besteht somit die Gefahr eine Entscheidung zu früh zu treffen, obwohl man die Notwendigkeit für das Domain Model Pattern erst später begründen können wird. Es besteht aber auch die Gefahr, sich mit der Wahl von Transaction Scripts oder Table Modul die Möglichkeit zu verbauen, jemals zu einem reichhaltigen Domänenmodell zu gelangen. Denn laut Fowler ist genau dieser Übergang extrem aufwending und teuer – obwohl die Alternative (kein Redesign) keine wirkliche Alternative ist. Interessant wäre wohl zu experimentieren, ob ein Redesign vom Domain Model Pattern hin zu Transaction Scripts gut funktioniert. Mein Tipp wäre, dass sich dies wohl leichter realisieren lässt, als der Weg anders herum; schließlich sehen wir heute viele Prozedurale Implementierungen mit einem anemischen Domänenmodell.

Klar ist, dass das Table Module Pattern gerade wegen seiner breiten Werkzeug-Unterstützung im .NET Bereich eine sehr geringe Hürde für den Einstieg hat. Table Module und Transactions Scripts zerlegen die Domäne in ein prozedurales Modell und bestechen durch ihre Einfachheit - für einfache Kontexte! Leider ist dieser Umstand bisher wenig bis gar nicht kommuniziert worden. Offensichtlich ist aber die Idee des simplen Drag&Drop / RAD / … für die meisten gescheitert. Beim Table Module Pattern gibt es in der Regel ein Objekt, dass die Logik und Kommunikation für eine Datenbank-Tabelle übernimmt. Transaction Scripts manifestieren sich in der Regel in einem “dicken” Application / Service Layer (Fowler). Für jede Transaktion haben wir dann eine Service-Operation. Hiermit sollte dann auch klar sein, warum beide Ansätze Probleme mit duplizierter Logik, Copy&Paste-Smells und vor allem Seperation of Concerns haben. Beim Einsatz eines Domain Models ist die Service Schicht hingegen sehr dünn. Sie koordiniert nur verschiedene Aktionen auf dem Domänenmodell. Vor allem aber eignet sich die Service Schicht zur Beschreibung der Session- und Transaction-Scopes zur Datenbank-Verbindung (mehr dazu später in der DDD Serie).

Transaction Scripts und Table Module haben sicherlich geringere Anforderungen an die Erfahrung und das Abstraktionsvermögen eines Entwicklers. Domänenmodelle bieten dafür weitaus mehr Modularisierung und können so auch zu mehr Wiederverwendung führen. Je komplexer ein Modell wird, umso mehr scheint der Vorteil gegeben über Transaction Scripts und Table Module zu wiegen. Sicheres Einsatzgebiet sind somit auf jeden Fall jene Domänen, bei denen von Anfang an klar ist, dass die Komplexität jenseits von einfacherer Validierung (zB isolierte Validierung pro Feld) und CRUD liegt.

Am Schluss möchte ich noch zu Bedenken geben, dass vollständige Modularisierung mit OOP nicht möglich ist (siehe “Tyranny of the dominant decomposition”). Egal nach welchen Kriterien die Dekomposition der Anwendung von statten geht – es wird immer orthogonale, übergreifende Belange geben. Nach derzeitigem Stand der Forschung erreichen wir damit noch bessere Modularisierung nur durch den Einsatz von Aspekt-Orientierung. Meines Wissens ist aber weiterhin unklar, ob wir damit den “heiligen Gral” der Modularisierung erreichen. Vielleicht ist es am Ende auch egal und nur eine Frage des nötigen Pragmatismus.

Technorati Tags: dotnet,domainmodel,domain driven design,ddd,patterns

ALT.NET Bier Köln #1

noreply@blogger.com (Sebastian Jancke) — Tue, 05 Aug 2008 23:05:00 +0000

Nachdem Stefan Lieser in Blog und Maillingliste bereits grob berichtet hat, folgen hier nun noch die visuelle “Nachverfolgung” des ersten ALT.NET Treffens in Deutschland überhaupt.

Stattgefunden hat das ganze in der Teba in Köln, wo auch die Treffen der DNUG Köln ihre Heimat haben. Themen waren unter anderem:

Mitarbeiter Motivation / Coaching in ALT.Net
Messaging statt RPC, Publish Subscriber
PostSharp erfüllt Obliviousness nicht
Parallelität

Speziell zum Thema PostSharp und AOP-Obliviousness möchte ich noch den folgenden Link zum entsprechenden Paper nachreichen: Robert Filman, Daniel Friedman: “AOP is Quantification & Obliviousness”.

Technorati Tags: ALT.NET,altnetde

.NET Open Space 2008

noreply@blogger.com (Sebastian Jancke) — Tue, 05 Aug 2008 22:55:00 +0000

Nun ist es also raus: am 18. und 19. Oktober 2008 findet die .NET Open Space in Leipzig statt. Dabei bildet ALT.NET eines der drei Themenfelder und verspricht spannende Sessions. Ort der Veransaltung ist der Mediencampus Villa Ida. Ich werde auf jeden Fall teilnehmen und habe mich bereits registiert. Vielleicht kommt ja auch eine Session zu DDD oder AOSD zustande – ich würde mich drauf freuen ;-)

Technorati Tags: ALT.NET,altnetde,netos2008

DDD – Allgegenwärtige / Universelle Sprache

noreply@blogger.com (Sebastian Jancke) — Fri, 11 Jul 2008 18:49:00 +0000

Bisher in dieser Serie: DDD – Eine Einführung

Die zentrale Technik im Domain Driven Design ist die “Allgegenwärtige / Universelle Sprache”, engl. ubiquitous language. Um zu erklären, wobei es darum geht, möchte ich zunächst weg von der technischen Sprache. Wir alle kennen das Phänomen, das manche Filme und Bücher in der originalen Sprache einfach aussagekräftiger und präziser sind. Übersetzungen gehen oft soweit, das Film- und Buch-Titel einfach die Aussage des originalen Titels kaum noch widerspiegeln. Übersetzungen erzeugen schlicht kleine Fehler und Abweichungen, die in der Summe (bei schlechten Übersetzungen) einfach nicht mehr die selbe Aussage treffen.

Übertragen wir diese Film-Metapher auf die Software Entwicklung. In manchen starren Prozessen gibt es Entwickler, Architekten und Analysten. Letztere kommunizieren direkt mit dem Kunden, übersetzten die Anforderungen des Kunden in die Sprache der Architekten und Entwickler. Meist haben Entwickler und Architekten kaum noch die selbe Sicht und Sprache auf die Domäne wie der Kunde. Wie wir bereits gesehen haben, sind solche Übersetzungen nicht trivial und fehlerfrei. Im Extremfall kommunizieren die Team-Mitglieder in einer anderen Sprache und damit mit einem anderen Modell, als im Quelltext des Systems abgebildet ist. Sicherlich kennt fast jeder solche Projekte und Situationen.

Evans schlägt hier einen Ansatz vor, der zunächst manchem radikal erscheinen mag. Aber wie bei allen neuen Techniken ist ein wenig Dogmatik der Verbreitung sicherlich dienlich (siehe zum Beispiel TDD). Evans schlägt eine vereinheitlichte Sprache zwischen Kunden und Entwicklern vor. Diese allgegenwärtige, universelle Sprache bildet das Modell der Domäne ab. Diese Sprache manifestiert sich in der Kommunikation zwischen Team und Kunden, in Dokumenten und natürlich auch im Quelltext. Sie ist das Kernstück, das Rückgrat des Modells und muss unbedingt von allen Mitgliedern des Team kommuniziert werden.

Interessant zu diskutieren wäre hierbei das gebräuchliche Vorgehen, Quelltext in englischer Sprache zu halten während wir fast alle auf Deutsch kommunizieren. Denn dies ist bei deutschsprachigen Kunden schließlich auch eine Übersetzung. Auf der anderen Seite gehört es zum “guten Ton”, Quelltext auf Englisch zu schreiben – wohl auch weil die deutsche Sprache teilweise einfach mehr Wörter zum Ausdruck braucht.

Die Wahl der Dokumentation ist unbedingt dem Kontext anzupassen, denn die allgegenwärtige Sprache wird sich über einige Zeit weiterentwickeln und ständig Verändern, bis sie sich in ihrem Kern stabilisiert hat. Für manche Projekte machen hier sicher starre UML-Diagramme und Anforderungsdokumente Sinn, wenn das Projekt nicht mit dauernden Änderungen in der Domäne umgehen muss. Für Domänen mit häufigen, ständigen Änderungen empfehlen sich dann wohl eher temporäre Diagramme (Skizzen). Evans gibt hierbei zu bedenken, das gerade Diagramme eher nur Ausschnitte des Modells reflektieren sollten. Gerade UML-Diagramme tendieren dazu, sich extrem zu vermehren oder aber allumfassend zu werden. Solche Diagramme sind sicherlich kaum zur Kommunikation geeignet, weil es viel zu lange dauert sie zu lesen und zu ändern. Gerade in der Anfangsphase der Modellierung ist das Modell in der Regel noch nicht Stabil genug. Hier sind Skizzen und Ausschnitte unter Umständen viel schneller von Hand zu erstellen als jedes andere Diagramm. Zu bedenken ist auch, dass je mehr komplexe Dokumentation des Modells es gibt, desto mehr Artefakte müssen auch synchron mit der Entwicklung der Sprache gehalten werden. Aus der eigenen Erfahrung kann ich berichten, dass in manchen Projekten einfache digitale Mindmaps ausreichen, um Änderungen an der Sprache (und damit auch an der Domäne) zu dokumentieren. Dies hat unter Umständen aber den Nachteil, dass alle Dokumente fast nur inkrementelle Ausschnitte sind. Auf der anderen Seite sind solche Mindmaps schnell geschrieben, strukturiert und auch schnell verstanden.

Egal welcher Ansatz gewählt wurde: Die Sprache und damit auch das Modell der Domäne manifestiert sich vor allem in der Kommunikation zwischen Team und Kunde und vor allem auch innerhalb des Teams. Dies bedeutet automatisch, dass jedes Konzept in der Sprache seine Entsprechung im Quelltext finden muss. Alle Änderungen in der Sprache sind somit auch eine Änderung am Modell. Somit muss dann auch der Quelltext die Änderungen mittragen. Andersherum kann es auch Konzepte geben, die bisher nur implizit vorhanden – und vielleicht bisher kaum verstanden - sind. Dies manifestiert sich vielleicht erst in der Entwicklung des Systems. Solche impliziten Konzepte müssen dann explizit gemacht werden und auch Eingang in die Sprache finden. Erst dann sind sie schließlich mit den Experten in der Domäne diskutierbar.

Unsere allgegenwärtige, universelle Sprache ist während der Modellierung natürlich Änderungen unterworfen - auch wenn wir Big-Design-Up-Front arbeiten. Dann gibt es diese Änderungen hoffentlich nur während der Modellierungs-Phase (was ich aus meiner bisherigen Erfahrung eher selten glaube). Dies kann dazu führen, dass dass Modell der Domäne nicht mehr mit den neuen Anforderungen skaliert. Dann ist es Zeit, Teile des Modells zu entfernen und neu zu beginnen. Dies erreicht man im Prinzip nur durch Experimenten mit dem Modell und Diskussion mit den Experten der Domäne. Beispiele für solche Vorgänge sind in den Büchern von Eric Evans und Jimmy Nilsson in vielen Beispielen zu finden.

Einen Vergleich, den ich sehr interessant finde, gibt es zwischen der allgegenwärtigen Sprache des DDD und der System-Metapher des eXtreme Programming. Die Metapher wurde in den ursprünglichen XP-Büchern kaum behandelt (nur auf wenigen Seiten) und ist daher vielleicht eine der kaum praktizierten Methoden (jedenfalls hört und liest man eher selten davon). Man kann die allgegenwärtige Sprache im Domain Driven Design als ein Schlüssel zur Erstellung einer solchen System-Metapher auffassen.

Abschließend ein Ausblick:

In den folgenden Teilen der Serie stelle ich den von Evans eingeführten Sprach-Elemente vor, um aus der Kommunikation mit Experten der Domäne dann ein Modell zu strukturieren. Weitere Teile werden Techniken enthalten um Konzepte im Quelltext expliziter zu machen, das Modell reichhaltiger zu gestalten, seine Anstrengungen in der Modellierung zu fokussieren und ein Modell gegen unerwünschte Einflüsse zu schützen sowie mit anderen Modellen zu integrieren.

Zum Schluss: ein gutes Beispiel für schwierige Übersetzungen ist schon der Titel dieses Beitrags: “ubiquitous langauge” lässt sich übersetzten, verliert dann aber schnell an Bedeutung – jedenfalls in meinem sprachlichem Empfinden.

Technorati Tags: ddd,domain driven design,domainmodel

DDD Serie:

DDD – Eine Einführung

DDD – Eine Einführung

noreply@blogger.com (Sebastian Jancke) — Fri, 11 Jul 2008 18:18:00 +0000

Dies ist der Beginn einer Serie zum Thema Domain Driven Design (DDD). Ich werde versuchen, die Serie mit weiteren Beiträgen zu füllen, während ich an einem Vortrag zum Thema arbeite.

Domain Driven Design ist der Titel eines Buches von Eric Evans. Das Buch selbst ist nicht mehr “ganz neu” – trotzdem gab es (gerade auch in den Java und ALT.NET Gemeinschaften) einigen “Hype” darum. Dabei gibt es eigentlich nicht genau das DDD. Zunächst ist DDD eine Kombination aus “Model Driven Design” (nicht zu verwechseln mit MDA – Model Driven Architecture) und Prozessen rund um Kunden-Kommunikation, Integration und Modularisierung verschiedener Domänen, etc..

Nun stellt sich natürlich die Frage, wann DDD eingesetzt werden sollte. Zunächst ist die Ansatz der allgegenwärtigen Sprache sicherlich universell nutzbar. Um den vollen Nutzen zu erfahren ist aber sicherlich die Kopplung mit Model Driven Design empfehlenswert. Ausgangspunkt ist das Domain Model Pattern von Martin Fowler. Hierbei sollen die kompletten Fähigkeiten unserer OOP-Sprachen genutzt werden, um die Komplexität der Domäne in ein reichhaltiges Objektmodell zu übersetzten.

Damit dürfte klar sein, dass Model Driven Design, also OO-Modelle der Domäne, sich vor allem in OLTP-Szenarios einsetzten lassen. Derzeit ist Objekt-Orientierung einer der stärksten Ansätze, die wir kennen, um hohe Modularisierung und Reduzierung der Komplexität zu erreichen.

Dies bedeutet aber auch, dass OLAP-Szenarios ungeeignet für den Einsatz eines reichhaltigen Objektmodells sind – denn hierbei geht es primär um die Analyse von Daten und weniger um komplexe Prozesse und Regeln innerhalb von Transaktionen. Die Frage nach Ad-hoc Reporting wurde auf der DDD-Mailingliste schon mehrfach gestellt und auch beantwortet – mittlerweile gibt es dazu auch einen Artikel und eine Diskussions-Zusammenfassung auf der Webseite zu DDD. Ich möchte hier nicht direkt im Detail darauf eingehen - dies werde ich zu einem späteren Zeitpunkt noch tun. Zusammenfassend möchte ich aber sagen, das solche Objektmodelle und damit verbundene Datenbank-Schemata eigentlich nicht zum performanten Ad-hoc Reporting geeignet sind. Alternativen wären flache, spezielle Datenbank-Sichten oder eine Art Data-Warehouse-Lösung.

Ziel des Model Driven Design ist also die Erstellung eines reichhaltigen Objektmodells, das wir mit völliger Freiheit unter Ausnutzung aller Sprach-Features erstellen. Zu starke Kopplung an die Infrastruktur (etwa Basisklassen mit Transaktions- und Datenbank-Logik) sind hier hinderlich. Deshalb ist der Begriff “Persistence Ignorance” eng mit der Erstellung solcher Objektmodelle verbunden. Objekte ohne Einschränkung durch Infrastruktur oder Runtime-Container (wie zB EJB 2.0 - Java , CSLA - dotnet) werden auch POCOs genannt – Plain Old CLR Objects. Ich würde sogar noch ein Stück weiter gehen und von Infrastruktur-Ignoranz sprechen, da Persistenz nur ein Aspekt der Infrastruktur ist.

Natürlich bedeutet dies auch, dass wir gewisse Anforderungen an die Architektur solcher Systeme haben, auf der anderen Seite aber auch eine Menge gewinnen. Zunächst möchte ich auf die Gewinne eingehen. Solche Objektmodelle eigenen sich perfekt um Komplexität zu verstecken und Änderung zu handhaben. Die Arbeit mit solchen Modellen führt zu ausdrucksstarken Kombinationen aus bereits bestehenden ausdrucksstarken Teilen. Damit gewinnen wir als Lesbarkeit und auch Wartbarkeit. Objektmodelle ohne Abhängigkeit von der Infrastruktur bedeuten natürlich auch einfache Testbarkeit. Somit ist es möglich, die gesamte komplexe Logik in Objektmodelle mit automatisierten Tests ständig zu überprüfen. Unsere Architektur wird hier also testbar und wir werden nicht gehindert Tests zu entwickeln oder gar Test-first (TDD) zu arbeiten. Solche Objektmodelle erleichtern die Arbeit mit automatisierten Tests geradezu.

Es gibt aber auch einige Anforderungen an unsere Architekturen, um solche reichhaltigen Objektmodelle im Sinne von DDD zu entwickeln. Diese sind nicht unbedingt negativ (haben sogar positiven Einfluss auf das gesamte System), sind teilweise aber fast Voraussetzung. Zunächst einmal lassen sich Infrastruktur-Ignorante Objektmodelle im Prinzip nur entwickeln, wenn wir das Dependency Inversion Principle anwenden. Dies führt sofort zur Notwendigkeit eines Dependency-Injection-Containers zur Konfiguration der Abhängigkeiten. Natürlich ließe sich das DIP auch anders realisieren, pragmatisch gesehen nehmen uns solche Container (Castle Windsor, Spring.NET, StructureMap, Ninject) aber sehr viel Arbeit ab. Der Einsatz eines solchen IoC/DI-Containers hat darüber hinaus einen positiven Effekt auf die gesamte Anwendung: lose Kopplung ist schließlich eine Eigenschaft, die man sich generell (neben hoher Kohäsion) für seine Module wünscht.

Soll unser Objektmodell persistiert werden, brauchen wir auch einen starken, flexiblen O/R-Mapper. In letzter Zeit gab es viel Rumoren um das Entity Framework – um es kurz zu machen: derzeit sieht sowohl das EF-Team als auch die ALT.NET Community das EF nicht als eine Option an, wenn man DDD nutzt. Derzeit stärkstes Framework auf dem Markt ist damit NHibernate, eine ehemalige Portierung des Java-Frameworks Hibernate. NHibernate ist komplett in das dotnet-Ökosystem integriert und weit verbreitet.

Die Entwicklung reichhaltiger Objektmodelle erfordert zudem generell eine Leistungsfähige Entwickler-Struktur, denn ohne gute, OOP-erfahrene Entwickler ist es schwierig ein reichhaltiges Objektmodell zu erstellen. Viele Entwickler sehen sich zwar als OOP-erfahren, doch ist es noch ein großer Unterschied eine OOP-Sprache wie C# einzusetzen oder aber gute, leistungsfähige Objektmodelle zu entwickeln. Dies merkt eigentlich jeder, der bisher noch nie mit aller Kraft versucht hat, ein Modell noch reichhaltiger zu machen. Die ersten Versuche scheitern wohl in der Regel (und sind es auch bei mir). Das eingestehen und sehen der Fehler ist hier der Schlüssel um sich weiterzuentwickeln. Viele open-source Projekte nutzen reichhaltige Objektmodelle und sind optimal zum Lernen.

Zum Schluss noch einige Worte zum Aufwand. Ein Objektmodell zur Repräsentation der Domäne zu erstellen ist harte Arbeit und aufwendig – dem gegenüber steht aber die Leichtigkeit mit der später Komplexität gehandhabt werden kann (wenn das Modell gut genug ist). Als Alternativen gäbe es noch die Arbeit mit Transaction Scripts (Fowler) oder dem Table Module Pattern (Fowler). Letzteres erfreut sich gerade bei .NET-Entwicklern großer Beliebtheit wegen der guten IDE-Unterstützung in Visual Studio, dort bekannt als DataSets. Für einen genauen Vergleich möchte ich auf Martin Fowler’s Buch “Patterns of Enterprise Application Architecture” verweisen. Es sei aber gesagt, dass gerade das Table Module Pattern wahrscheinlich am wenigsten mit steigender Komplexität der Domäne skaliert, gefolgt von Transaction Scripts. Beide haben vor allem das Problem von Copy&Paste-Smells und Dopplung von Logik. Nach derzeitigem Stand ist ein objekt-orientieres Modell das einzige, das wirklich besser mit wachsender Komplexität skaliert. Problematisch ist allerdings, dass man Komplexität schlecht messen kann und keiner genau weiß, wo die Schwellwerte liegen. Letzten Endes ist hier die Erfahrung und Experimente / Prototypen gefragt.

Technorati Tags: dotnet,domain driven design,ddd,domainmodel

Objekt-Modellierung: Nomen? Verben? Beides? Keins?

noreply@blogger.com (Sebastian Jancke) — Tue, 08 Jul 2008 16:33:00 +0000

Die allermeisten lernen wohl OOP – bis heute – in seiner einfachsten Form zunächst als “Finding the nouns”. Die Nomen finden – und dann daraus Objekte machen. Fehlen noch Aktionen, um daraus Methoden für ein Objekt zu erstellen – wie gut das es ja noch Verben gibt.

Vielen Entwicklern dürfte klar sein, dass diese Schema zu simpel ist und höchstens für die ersten OOP-Beispiele ausreicht. Fortgeschrittenere “Richtlinien” und Möglichkeiten zur Strukturierung bieten unter anderem der DDD-Prozess, und das Entity-Controller-Boundary Modell.

Trotzdem habe ich schon zu oft Entwickler gesehen, die krampfhaft versuchen, ein Objekt nach Nomen zu benennen, obwohl ein Verb viel aussagekräftiger wäre. Das Resultat sind die allerseits beliebten Konstrukte:

AnotherCarFinder.FindCar(myCarId);

Neben der Dopplung – die sich sehr holprig liest – ist das ganze auch kaum aussagekräftig. Deshalb wäre mein Ratschlag: Weg vom OO-Denken in Nomen, hin zu mehr Flexibilität und Kreativität.

Das obige Beispiel sieht so sicherlich viel lesbarer aus:

FindAnotherCar.By(myCarId)

Dies ist sicherlich noch nicht das non-plus-ultra und auch nicht das Ende der Möglichkeiten. Deshalb möchte ich alle Leser auffordern, mir ihre Beispiele und Ideen doch vielleicht zukommen zu lassen. Mich interessiert brennend, welche Techniken andere (unter anderem) nutzen, um die Lesbarkeit zu erhöhen.

Technorati Tags: domainmodel,readability,maintainability,dotnet

“ORMs für .NET im Vergleich” – Eine kleine Kritik

noreply@blogger.com (Sebastian Jancke) — Wed, 02 Jul 2008 21:44:00 +0000

Nach Monaten ohne (öffentliche) Reaktionen und einer Diskussionen auf der ALT.NET.DE Mailing-Liste will ich versuchen, meine Kritik am Artikel “Objektrelationale Mapper für .NET im Vergleich” zu formulieren. Der Artikel wurde von Holger Schwichtenberg geschrieben und in dem Magazin dotnetpro (Ausgabe 4/2008) publiziert.

Da dieser Artikel sicherlich auch von Einsteigenden gelesen wird, oder von Menschen ohne Erfahrung speziell mit NHibernate, finde ich es wichtig, dass keine Halb-Wahrheiten stehen bleiben. Dieser Eintrag soll ein Versuch sein, mit einigen Fehlern und Missverständnisse im besagten Artikel aufzuräumen. Die Aufstellung ist sicherlich nicht komplett und ich maße mir auch keinerlei Wertung über den Artikel oder das Magazin oder den Autor an.

(Abschnitt: Henne oder Ei) Beim Forward Mapping machen NHibernate und das ADO.NET Entity Framework bislang nicht mit; sie können eine Datenbank nicht auf Basis von Geschäftsobjekten generieren.

Ich zitiere dazu (frei) aus der NHibernate Dokumentation, Abschnitt 3.5 “Optional configuration properties”: Die Eigenschaft “hibernate.hbm2ddl.auto” bestimmt, ob das DDL Schema automatisch bei Erzeugung der ISessionFactory exportiert werden soll. Mögliche Werte sind unter anderem “create” und “drop”. Mit “create-drop” wird das Datenbank-Schema zunächst erzeugt und beim Schließen der ISessionFactory dann gelöscht. Ich kann jedem nur empfehlen, diese Optionen auszuprobieren. Bisher habe ich sie auf Entwicklungs-Datenbanken erfolgreich nutzen können, um meine Produktivität in diesem Bereich zu steigern. Gleichzeitig halte ich eine Kopie der bisher ausgelieferten Datenbank vor. Mit Werkzeugen wie “Quest Comparison Suite” oder “RedGate SqlCompare” kann ich dann zum Ende einer Iteration die Änderungen automatisiert in ein Script übertragen lassen.

(Abschnitt: Geschäftsobjektklassen) Die Fachwelt spricht dann von Persistance Ignorance oder von Plain Old CLR Objects (POCOs). In diese Kategorie fällt NHibernate. NDO kann POCOs als Unterobjekte eines zu persistierenden Objekts verwenden.

Hierbei geht wohl die eigentliche Bedeutung des Wortes “POCO” verloren. Frei nach Fowler ist ein POCO ein “Plain Old CLR Object”. Also ein Objekt, das sonst keine Abhängigkeiten und Einschränkungen hat. Vererbung ist vielleicht die stärkste Form der Abhängigkeit. Durch Vererbung von einer zentralen Basisklasse meines Persistenz-Frameworks gehe ich somit eine sehr starke Abhängigkeit ein. Das Objekt ist somit kein POCO mehr. Die Begriffe POJO und POCO implizieren damit im Bezug auf Persistenz auch direkt einen Teil des Begriffes “Persistence Ignorance”. NDO ist somit nicht PI-fähig und die Geschäftsobjekte in diesem Zusammenhang sind keine POCOs.

(Abschnitt: Mapping und Treiber) Nicht alle Werkzeuge verwenden im Untergrund ADO.NET. VOA und NHibernate arbeiten mit JDBC (Java Database Connectivity), da es sich um Portierungen aus der Java-Welt handelt.

Dazu möchte ich wieder die NHibernate Dokumentation frei zitieren, im speziellen den Abschnitt 2 “Architecture”: NHibernate kann grundsätzlich auf zwei Arten eingesetzt werden: Entweder die Anwendung stellt NHibernate die entsprechenden ADO.NET Verbindungen zur Verfügung, oder aber NHibernate schirmt die Anwendung von der gesamten Datenbank-Kommunikation ab. Wie man in diesem Fall an der entsprechenden Grafik ("full cream" architecture) sehen kann, liegt auch dann ADO.NET (neben OLE DB und ODBC) zu Grunde. Noch deutlicher ist die Beschreibung des Interfaces ISession: “… kapselt eine ADO.NET Verbindung”.

Abschließend möchte ich noch einige Worte zum Fazit des Autors verlieren. Herr Schwichtenberg legt in seinem Vergleich anscheinend sehr viel Wert auf die Unterstützung mittels grafischer Werkzeuge. Ich kann diese Wahl der Kriterien nicht teilen und auch nicht unterstützen. Für Einsteigende mögen grafische Werkzeuge am Anfang sehr eingängig und leicht zu erlernen sein. Ich bezweifle allerdings, dass die “Dekoration” der Geschäftsobjekte mit Attributen schwieriger ist. Dies ist zwar kein “best practice” – da wir die Persistence Ignorate verlieren – ist aber für den Einstieg akzeptabel.

Schwerer wiegt für mich aber noch das Argument der Skalierbarkeit solcher grafischer Werkzeuge. Dazu reicht meist schon der Versuch, eine “mittelgroße” Anwendung (vielleicht 2-3 Mannmonate Aufwand?) in solch einem grafischen Werkzeug darzustellen. Hierbei scheitert derzeit vor allem der Entity Framework Designer – es werden schlicht alle Objekte auf der gesamten “Leinwand” dargestellt (Scott Allen - Visual Designers Don’t Scale). Auch mit Zoom-Funktion, Gruppierungen und Ausschnitte bleibt immer die Tatsache, das visuelle Werkzeuge in der Regel (bisher) einfach schlecht mit der Größe des Domänen-Modells skalieren.

Technorati Tags: orm,nhibernate

Auf zu neuen Ufern

noreply@blogger.com (Sebastian Jancke) — Wed, 02 Jul 2008 21:44:00 +0000

Anlässlich der Diskussion auf der deutschen ALT.NET Mailing-Liste zum Thema: “Deutschsprachige Inhalte rund um ALT.NET” und der Tatsache, dass ich mich aus meiner Blog-Lethargie befreien möchte:

Ab jetzt ist hier alles in Deutsch geschrieben (naja fast alles) ;-)

Improving Agility in Visual Studio

noreply@blogger.com (Sebastian Jancke) — Thu, 31 Jan 2008 12:46:00 +0000

What Visual Studio (2005) Professional lacks out of the box, is a good support for unit testing and build scripting. Actually, VS2005 Pro does not provide any support for it. So in case you don't want to buy the Team Edition (for testing support), looking for a free alternative, the following might be a solution.

TDD (with NUnit) is definitely at the heart of my day-to-day development process. But I was in a snit to call NUnit-GUI-Runner from the custom tools menu. Further, I needed a possibility to automate my release processes (compile, test, commit, tag, zip, name with version). On the java side of our dev world, I was used to Ant. And happily, there is a .NET alternative to crude MSBuild: NAnt.

Without going into the details of NAnt, one can say: NAnt is XML-based, easy to use, has a bunch of tasks and plugins for all sort of things (vcs's, io, vs-solution stuff, compression, ...) and can be easily extended with your own tasks/plugins. What's really cool about NAnt is the fact that it's Ant for .NET - I don't need to relearn anything and can reuse my knowledge of Ant (which is the standard build scripting system in the Java/eclipse world).

Using these visual studio addins:

saved my day-to-day dev life.

Courtesy of Eric Harth and Olivier Chekroun

Running NAnt scripts is fairly easy. Running NUnit tests directly within the IDE (without buying TestDriven.NET) made my day. Both addins are written for Visual Studio 2005 (I don't know about compatibility with 2008). They are easy to install and use.

Both addins accelerated my development process a lot, because I don't need to leave the IDE any more for testing and my release process is now automated

Perhaps, one day someone ports these for VS 2008 (if they incompatible). Both are open source, so this task should be pretty easy.

Technorati-Tags: dotnet,nant,nunit,tdd,visualstudio,plugin

Presenter First - MVP put into an agile process

noreply@blogger.com (Sebastian Jancke) — Wed, 12 Dec 2007 09:45:00 +0000

Last time, I have tried to show, how do decouple the presentation layer. Today the topic or point of view is slightly different. The Model-View-Presenter patterns can be integrated as default construction of your presentation layer into your development process. Atomic Object has build a complete agile process around the MVP pattern, called "Presenter First". This process includes Test-Driven-Development (TDD), Story-Driven-Development and the MVP pattern.

The Model-View-Presenter pattern can be used to build domain logic and presenters based on the user stories, without a single line of UI code (or a single click). The views are all mocked out using a mocking framework (JMock, EasyMock, NMock, RhinoMock, ...). All domain logic and presentation logic is tested in isolation, the presenter comes first (well, before the view).

So I would see this process broken down into the following steps:

Write a unit test, covering your user story in the domain layer
Fulfill with domain code, until green
Write a unit test for your presenter
Fulfill with presenter code, until green
Write an integrative unit test from the presenter down to the domain (at least you should)
Now it's time to build some UI

My conclusion is, that the Model-View-Presenter pattern really decouples any UI concerns from the actual user stories and their presenter/domain implementation.

Technorati-Tags: process

Reference Material: Atomic Object - Presenter First

Decoupling presentation logic with MVP

noreply@blogger.com (Sebastian Jancke) — Fri, 07 Dec 2007 00:55:00 +0000

Motivation

Lot's as been written on decoupling presentation logic since the ages of Smalltalk and the MVC-Framework. But still today, even in medium sized projects (far beyond the stage of prototype), developers - and that's me also - tend to put far too much code into the UI layer. Simultaneous, details on validation and security constrains applied to the UI have mostly left out.

What's the problem?
The problems do not show up immediately, but after some time and growth. Most know, that putting domain logic into the UI layer is one of the worst habits. But few identify presentation logic in the UI-Implementation as a source of high coupling and low cohesion.

This is in conflict with one of the most basic rules of object oriented design principles: Subsystems should be highly cohesive and have low coupling. Some guys out there have a pretty short answer: "Using partial classes [in C#] decouples UI controls and logic". They fail to recognize, that partial classes in C# split a class across several files - but it does not bring in low coupling, as it is still one class.

Looking at the widespread known patterns discussed by the GoF, one can notice that there are couple of patterns with "Split Object" behavior: Decorator, Compositor, Proxy, Strategy, ...

What we need is a similar "Split Object" solution for decoupling of UI implementation and presentation logic concerns.

A possible solution
Since the ages of Smalltalk, we (should) know MVC - Model View Controller. It is a simple and working pattern for presentation logic decoupling. So why switching minds and using another one? What MVC fails, is to enable isolated unit testing. The guys of Atomic Objects noticed that [Atomic Objects Agile2006] and introduced the MVP - Model View Presenter pattern. Fowler has gone even further and split this pattern into two: Supervising Controller [Fowler EAA, SC] and Passive View [Fowler EAA, PV].

Passive View
Passive View reduces the UI (read: the views) to its absolute minimum. The difference to Model-View-Controller is that the view does not care about changes in the model. The presenter is in charge of updating the view with any changes in the model. Events on the view are subscribed by the presenter, views do not change the model.

As a direct result, all view logic lives in the presenter (sometimes also called controller, as this can be considered a MVC variant). The view and the model do not know of each other and have no direct reference.

Implementing it results in chatty interfaces between presenter and view, as all shown fields are transferred through properties on the view interface. I see it as an disadvantage, especially on complex objects. Supervising Controller can help, but it depends (as always) on your context.

A nice side effect is the following: Passive View makes it possible to implement views, that are totally unaware of your domain model. Splitting these layers into different subsystems (to be language and platform neutral) makes it physically nearly impossible to put business concerns into the views.

Supervising Controller
Passive View is a nice solution, as it fits our needs and decouples the presentation logic. Still it has some drawbacks. Data binding is the most important. Current view technologies have advanced support for (object) data binding. Using it can make your life a lot easier, writing less mapping code transferring values from and to the views.

Supervising Controller stands in. Presentation logic and command execution on view-events is still task of the presenter. Simple data mapping is done declaratively by the frameworks data binding. This solution lacks the ability to split view and presenter/model physically. Still it has the advantage of less code by using data binding.

Handling modal state
Presenters lack a concrete coupling to the view implementation. Unanswered is the task of showing model dialogs (Message Boxes) and asking the user for information (File selection, ...). Directly using message boxes in the presenter is generally a bad idea. It prevents us from isolated testing and worse: from testing at all.

A better approach is using the most valuable weapon in computer science - abstraction. We create a thin interface:

public interface IHumbleMessageBoxService
{
bool AskYesNoQuestion(string title, string message);
}

Our view subsystem implements this interface, for example with a standard message box. This service is injected into the presenter (follow up: Dependency Inversion), communication is only going through this interface. The presenter is unaware of the message box details, model dialogs, etc.

Using this approach now enables us to use unit testing again on our presenters. Generally everything should be decoupled by dependency inversion - it makes your testing life easy and your design more flexibly and explicit.

Validation
I consider validation as an integral part of the business logic. Complex validation rules regarding more than simple per-field checks are near to impossible to implement correctly in the UI (without high efforts). Those validation rules can be easily implemented in the domain model. Using current technology for declarative validation checks (Spring.Validation (Java, .NET) and MS Validation Block) make this task easy. Executing those checks should be initiated from the presenter, pushing the results (read: all at once) to the UI.

The habit of using the default "ErrorProvider" of .NET's Windows.Forms is a bad idea, because it locks the user to the current field, triggering errors. Complex validation rules require the presentation of all errors at once, thus triggering of the complete validation in the presenter is key. You may start to think, how popular "complex" rules are. The most "complex" rule one may think of is two date fields as input for a date range.

Further, there are several types of validation rules in a system. Some are part of your business requirements, but some are introduced by a certain persistence architecture(files, databases, ...). Not aggregating all types of rules in the domain layer results in wide spreading of validation concerns. Mediating validation and their results to the views is naturally placed in the presenter. No one (?) wants his UI layer to talk directly to services and operations of the domain layer.

Security
Securing operations on the domain layer is easily achieved with declarative and imperative security. Microsoft Security Block (Part of Enterprise library) is capable of both, using Aspects for this task can be easily implemented with Spring.Aop in Java and .NET. Currently this is the way, security is build into famous frameworks like JBoss Seam.

While it is acceptable for users of web applications to read "Operation not allowed", it is definitely not for rich desktop applications. I expect the same to happen in the field of AJAX enabled web applications. The question is: how can we prevent the user right in the UI layer from trying to execute certain operations?

In our domain model, we should have all operations available. Using declarative security is key here, because it clearly states security constrains at well defined,

Generically, we need to access these security attributes through reflection. For those in the .NET world and using Microsoft's IPrincipal:

bool roleMemberFlag = Thread.CurrentPrincipal.IsInRole("CanApproveClaims");

this is an easy task. It enables us to access security information for certain fields and operations via reflection. The presenter enables and disables the involved controls. Try doing that directly in your "code behind" of Dialogs, wihtout messing up all of your code.

Better design with higher effort?
Using the MVP pattern (and using patterns in general) rises the question of effort and results. In our case, testing presentation logic with unit testing the presenters in isolation is simpler and easier than any complex blackbox testing at the UI front.

Further, we gain more flexibility, code reuse and a design that meets object oriented principles. On the effort side, extracting an interface is of actually no cost, using today's refactoring support available.

Technorati-Tags: patterns,domainlayer,presentationlayer

{ Sebastian Jancke, ein Blog }

Architecture.NET Open Space 2009

Testing SyntaxHighlighter 2.0

ASP.NET MVC: Keine Präsentations-Belange im Controller

ALT.NET DE Online Meeting # 2 - DDD

Zum Jahresende: Koordinierte Weltzeit und irdisches Schwanken

ALT.NET Cologne #4 – Buildmanagement

BDD dein MVC

Eingesetzte Frameworks

Entwicklung eines Controllers anhand einer Userstory

Der beschriebene Quelltext

.NET Open Space 2008 rekapituliert

.NET Open Space 2008, Twitter

DDD – Vortrag in Köln (UPDATE)

DDD – Vortrag bei DNUG Köln, 07-10-2008

Aspektorientierung – der natürliche nächste Schritt

Was ist Domain Driven Design?

Bisher in dieser Serie:

DDD – Eine Einführung,

DDD – Allgegenwärtige / Universelle Sprache

Komplexität in Geschäftslogik

Ein Vergleich der Patterns Table Module (DataSets,..), Transaction Scripts und Domain Model

ALT.NET Bier Köln #1

.NET Open Space 2008

DDD – Allgegenwärtige / Universelle Sprache

Bisher in dieser Serie: DDD – Eine Einführung

Abschließend ein Ausblick:

DDD Serie:

DDD – Eine Einführung

Objekt-Modellierung: Nomen? Verben? Beides? Keins?

“ORMs für .NET im Vergleich” – Eine kleine Kritik

Auf zu neuen Ufern

Improving Agility in Visual Studio

Presenter First - MVP put into an agile process

Decoupling presentation logic with MVP

Motivation