|
|
Featured White Papers
Sponsored Links
-
Slow Apps? Overloaded DBMS? - FREE Download
FREE Download Feb 14 - March 7th Eliminate bottlenecks & maximize performance ScaleOut StateServer®
Domain-driven design with Java EE 6
An object-oriented architecture for interactive applications
- Feedback
- Discuss
For Java EE applications based on type-dependent algorithms, a domain-driven design that leverages object-orientation is better than a procedurally implemented service-oriented architecture. Adam Bien explains how and why object-oriented persistence makes your domain-driven application's code more efficient, maintainable, and testable. Level: Advanced
In "Lean service architectures with Java EE 6," I discussed how to implement a maintainable service-oriented architecture (SOA) that is based on anemic persistent objects and transient, stateless services. In this follow-up article, you'll learn about an architectural approach that is the exact opposite of that. What ties together the two architectures is that both can be implemented with Java EE 6 and, in particular, Enterprise JavaBeans (EJB).
As I'll explain in this article, you can build domain-driven applications with "real" objects -- objects that comprise encapsulated state and well-defined behavior. Whereas SOA is stateless and tries to hide a component's implementation, domain-driven applications are mostly stateful and aim to expose the domain objects to the user as directly and conveniently as possible.
Procedural vs domain-driven design
The vast majority of J2EE and Java EE applications are built in a procedural way. The business logic is decomposed into tasks and resources, which map, respectively, to services and anemic, persistent entities. Such an approach works surprisingly well until type-specific behavior for domain objects must be realized. Then the lack of object orientation in the persistence layer can cause problems.
Attempts to implement object-oriented algorithms with procedural techniques end up in many instanceof checks and/or lengthy if-statements. Such type checks are required because in the SOA world, domain objects are anemic, so inheritance doesn't pay
off. Even if inheritance is used to design the domain model, object orientation's most powerful feature -- polymorphic behavior
-- isn't leveraged at all.
The anemic domain model forces you to implement type checks outside the anemic entities, in services or service facades. To make their internal state accessible to the services and service facades, the anemic structures (technically they are not objects, by definition) must expose their internal state to the outside world too -- through field accessors (getters/setters) -- requiring a lot of plumbing.
In data-driven use cases such as master data management (CRUD), you can implement workflow-related, procedural behavior efficiently with service facades and few anemic entities. A domain-driven architecture, on the other hand, is perfect for more-complex, type-dependent algorithms in more-interactive applications. Most nontrivial Java EE projects require both approaches.
Essential ingredients of domain-driven design
The crucial artifact in any domain-driven application is a domain object. A domain object can be considered a real-world artifact in the given project context. The challenge is to grasp the context and not try to model a perfect, theoretical world. Pragmatism rules. Domain objects are just cohesive classes with encapsulated state and related behavior. They use inheritance naturally, where appropriate.
- Feedback
Resources
- "Lean service architectures with Java EE 6" (Adam Bien, JavaWorld, April 2009) describes a SOA based on anemic persistent objects and transient, stateless services.
- Also see Adam's earlier article on JavaWorld, "EJB 3: From legacy technology to secret weapon" (October 2008), in which he argues that convention over configuration, annotations, dependency injection, and aspect orientation have made modern EJBs a lean alternative to XML-laden and JAR-heavy frameworks.
- Martin Fowler explains why the Anemic Domain Model is usually suboptimal.
- Explore the EJB 3.1 and JPA 2.0 specifications.
- EJBs are now so lightweight that they beg the question "EJB 3.1 - And Is There Still Room For POJOs?" (Adam Bien's Weblog, January 2009).
- Read "Should JPA Entities Contain Business Logic? ...Why Not?" (Adam Bien's Weblog, February 2009) for a discussion of putting business logic into persistent entities.
- Read more about the revival of object-oriented development with Java EE in Fluent Interface Pattern with EJB 3 and JPA - a working sample (Adam Bien's Weblog, December 2007).
- Check out these 15 Tips on JPA Rich Domain Modelling - Thinking In Objects - Not Mappings [For Greenfields] (Adam Bien's Weblog, January 2009).
- The gateway solution in this article might shock advocates of the Core J2EE Patterns.
- The Naked Objects Framework offers an extreme form of direct exposure of PDOs to the presentation tier.
- Understand the concept of leaky abstractions:
- Leaky abstraction (Wikipedia).
- "The Law of Leaky Abstractions" (Joel Spolsky, Spolsky on Software, November 2002).
- The profiler shipped with NetBeans 6.5/6.7 supports remote profiling.
More from JavaWorld
- See the JavaWorld Site Map for a complete listing of research centers focused on client-side, enterprise, and core Java development tools and topics.
- JavaWorld's Java Technology Insider is a podcast series that lets you learn from Java technology experts on your way to work.
- Network World's IT Product Guides offer side-by-side comparison of hundreds of products in over 50 categories.
About Us | Advertise | Contact Us | Terms of Service/Privacy
Copyright, 2006-2010 Infoworld, Inc. All rights reserved.
DDD and JEEBy Anonymous on March 15, 2010, 9:31 pmDDD should not, also can not depend on JEE. DDD builds models and JEE is a pltform. Look what happened when people rush to adapt EJBs.
Reply | Read entire comment
"There is no relationshipBy Anonymous on February 7, 2010, 11:45 pm"There is no relationship between DDD and JEE" You don't really understand, do you... DDD is a concept (architectural style). You can implement it using JEE,...
Reply | Read entire comment
The point is clearBy Anonymous on January 21, 2010, 3:58 amWell, looks like several of you guys (commenters) don't understand the topic and that's becouse you don't understand what is the diference between a anemic domain...
Reply | Read entire comment
QuestionBy Anonymous on January 4, 2010, 10:59 pmWhats the advantage compare with using Spring with DDD?
Reply | Read entire comment
This is wrongBy Anonymous on December 3, 2009, 9:31 pmThe title is already wrong. I don't even feel like to read the article. There is no relationship between DDD and JEE. Come on!
Reply | Read entire comment
View all comments