Domain Driven Design

In vielen Anwendungen wird die Geschäftslogik im Service- bzw. Application-Layer untergebracht: CustomerMgmgService, OrderMgmtService, ProductMgmtService usw. Diese Aufteilung ist meist zufällig gewählt, ist mit der Zeit schwer zu verändern und führt häufig zu Duplizierung von Logik, wenn die Anwendung komplexer wird.

Eine Möglichkeit dem zu entgehen, ist die Aufteilung in Use-Cases, Prozesse, Unterprozesse und – als kleinste Einheit – schließlich Business Rules. Der DDD-Ansatz versucht das Problem eher über die Möglichkeiten der Objektorientierung zu lösen und sich damit mehr an der realen Welt zu orientieren.

Eine Herausforderung bei der Implementierung von DDD ist der Wunsch, sämtliche fachliche Logik im Domain-Model unterzubringen, dieses aber zugleich mit möglichst wenig (technischen) Abhängigkeiten zu versehen, so dass es leicht getestet und refactored werden kann – schließlich ist das eine der wichtigsten Anforderungen an die Geschäftslogik.

In Java ist das nicht ganz so einfach. Der verbreitetste Ansatz scheint die Nutzung von sogenannten Domain Events zu sein:

Rickard Öberg versucht einen anderen Ansatz, in dem er Java und die Fähigkeit zu Mixins und Traits erweitert: http://www.qi4j.org/. Eine Einführung gibt es unter: http://www.infoq.com/

Das könnte Dich auch interessieren …

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Durch die weitere Nutzung der Seite stimmst du der Verwendung von Cookies zu. Weitere Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden.

Schließen