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/
