Intro
Speaker's Qualifications
Overall Presentation Goal
Achieving DDD the right way
Agenda
What is DDD?
A brief look at current status
Obstacles in achieving DDD
Overuse of service layer
Two categories of services
AOP's role in DDD
Agenda
Domain model: Nice and clean!
Crosscutting concerns: Uh Oh!
Service layer to help - 1
Service layer to help - 2
Service layer to help - 3
AOP to help service layer
Aspects to replace service layer
Agenda
What do we inject?
Need for fine grained DI
Coordination through service layer
Fine grained injection
DI using aspects: General scheme
Example: Fluent interfaces
Code with regular interface
Code with domain-specific fluent interface
Order implementation - 1
Order implementation - 2
Spring configuration
Zone of trust enforcement
Example: Factory-only creation
Agenda
Crosscutting domain logic
Retry with alternative services - 1
Retry with alternative services - 2
Configuring aspect in Spring
Put good history to good use
But ensure payment before shipment
Agenda
Service layer gone?
The thought process
Refactoring to DDD
Summary
What we learned ?
References - 1
References - 2
Domain Driven Design (DDD) suggests dealing with complex software system using a domain model and preserving the model in implementation. Since domain model entities have rich behavior, so should their software implementation artifacts. A direct mapping between domain model and software artifacts create simple-to- understand, inexpensive-to-implement, and easy-to-evolve systems.
While the idea behind DDD isn't new and the value is easily understood, many implementations do not adhere to its principles. This disconnection may be due to many obstacles in implementing it. Combining Dependency Injection (DI) with a full-fledged aspect-oriented programming (AOP) system such as AspectJ help overcome many obstacles.
The traditional DI mechanism allows injecting dependencies into coarse-grained objects such as services exposed to the application level. However, it cannot do the same for fine-grained domain objects, which are not exposed in the same manner. The DI and AOP combination overcomes this limitation allowing creation a web of domain objects mirroring the model. Now domain classes can implement rich behavior by collaborating with dependent objects, instead of acting as mere data carriers. Further, domain concepts such as security, change tracking, and business rules are crosscutting in nature. AOP allows expressing these concepts directly using aspects.
In this talk, Ramnivas Laddad will examine the need for domain driven design, obstacles in achieving it, the basics of enabling behavior-richness for domain objects, and patterns of usages. This session will also present several examples that show the power behind the techniques. The knowledge gained through this session will enable you to readily apply domain driven design in your systems.
Ramnivas Laddad is an author, speaker, Interface21 consultant, and trainer specializing in aspect-oriented programming and J2EE. His most recent book, "AspectJ in Action: Practical aspect-oriented programming" (Manning, 2003), has been labeled as the most useful guide to AOP/AspectJ.
He has been developing complex software systems using technologies such as Java, J2EE, AspectJ, UML, networking, and XML for over a decade.
Ramnivas is an active member of the AspectJ community and has been involved with aspect-oriented programming from its early form.
He speaks regularly at many conferences such as JavaOne, No Fluff Just Stuff, Software Development, EclipseCon, and O'Reilly OSCON. Ramnivas lives in San Jose, California.