Rod Johnson: Are we there yet?
- Share
-
- |
Read later
My Reading List
We've come a long way from the first versions of J2EE. We've learned to avoid invasive programming models, we've developed a rich set of frameworks and APIs, we know how to develop applications based around simple objects. Are we there yet? Most of us would answer no to that question. If we're not there yet, then where are we headed next? Spring founder Rod Johnson explores this issue. The talk was recorded in Sept 2006 at the JAOO conference in Denmark, sister conference to QCon.
Watch Are we there yet? (59 min)
The the talk traces how we got here, starting in 2000-2003 when open source didn't play a big role in the definition of the programming models. Rod challenges the early assumptions that J2EE was built on, such as the aims to hide everything from developers, or waiting for tools vendors to simplify our lives.... "But tools that generate complex artifacts largely proved dead", as opposed to tools that work well with POJOS.
Rod then makes the point that innovation in the Java space saw a "move from leadership by committee to leadership from the community." Declaring the POJO as the defacto programming model that we'ved moved towards, Rod then evaluates various trends and techonologies supporting better OO including Domain Driven Design, AspectJ, DI, various features of Spring, and takes special care to show how the features in EJB 3 (excluding JPA) is insufficient for proper OO compared to Spring & AspectJ.
Rod's conclusions on where we are:
5 comments
Watch Are we there yet? (59 min)
The the talk traces how we got here, starting in 2000-2003 when open source didn't play a big role in the definition of the programming models. Rod challenges the early assumptions that J2EE was built on, such as the aims to hide everything from developers, or waiting for tools vendors to simplify our lives.... "But tools that generate complex artifacts largely proved dead", as opposed to tools that work well with POJOS.
Rod then makes the point that innovation in the Java space saw a "move from leadership by committee to leadership from the community." Declaring the POJO as the defacto programming model that we'ved moved towards, Rod then evaluates various trends and techonologies supporting better OO including Domain Driven Design, AspectJ, DI, various features of Spring, and takes special care to show how the features in EJB 3 (excluding JPA) is insufficient for proper OO compared to Spring & AspectJ.
Rod's conclusions on where we are:
We’ve made huge progress since 2003:
- But we’re not there
- We’ve fixed most of the flaws in the existing model
- But there is more to do
We need to finish the process of freeing the power of Java
- True objects
- Rich domain models
We need to challenge some of our old assumptions
- Do they hold today?
- Need to consider the place of dynamic languages on the Java platform
Community comments
Circular dependencies?
by
Oliver Gierke
Posted
Re: Circular dependencies?
by
Sato Tadayoshi
Posted
Great stuff. Let's go further.
by
Eelco Hillenius
Posted
Deep trouble
by
John Harby
Posted
Good summary
by
Rickard Öberg
Posted
Circular dependencies?
by
Oliver Gierke
Nice one again, injecting domain model classes leads to circular dependencies between service layer and domain layer in my opinion. Consider following packages
foo.bar.pethealth.domain
foo.bar.pethealth.service
foo.bar.pethealth.service.impl
domain contains all domain classes as Vet, Pet a.s.o., service contains interfaces exposed to clients and service.impl contains the actual implementations. So I am forced not to have a domain object in the IdentityTagRegistrationService interface to not create a circular dependency.
Okay, this question lead to the question if its reasonable to expose domain objects to service clients, but for some applications it would be overhead to create DTOs for that purpose 'cause you simply would copy most properties and getters and setters from the domain object to the DTO class and thus duplicate code and create (unnecessary) complexity. All the DTO would be quite anemic, too.
Perhaps in the next lower layer the problem becomes more obvious. What if I need to save objects in the logic, or retrieve further objects? DAO interfaces obviously have to expose domain objects. If I had a dependency to the DAO in the domain object then, the circle s perfect.
Any thoughts on that?
Regards
Ollie
foo.bar.pethealth.domain
foo.bar.pethealth.service
foo.bar.pethealth.service.impl
domain contains all domain classes as Vet, Pet a.s.o., service contains interfaces exposed to clients and service.impl contains the actual implementations. So I am forced not to have a domain object in the IdentityTagRegistrationService interface to not create a circular dependency.
Okay, this question lead to the question if its reasonable to expose domain objects to service clients, but for some applications it would be overhead to create DTOs for that purpose 'cause you simply would copy most properties and getters and setters from the domain object to the DTO class and thus duplicate code and create (unnecessary) complexity. All the DTO would be quite anemic, too.
Perhaps in the next lower layer the problem becomes more obvious. What if I need to save objects in the logic, or retrieve further objects? DAO interfaces obviously have to expose domain objects. If I had a dependency to the DAO in the domain object then, the circle s perfect.
Any thoughts on that?
Regards
Ollie
Re: Circular dependencies?
by
Sato Tadayoshi
Oliver,
If we recognize IdentityTagRegistrationService as a "Service" in the DDD sense, it is also a domain element so no circular dependency occurs. (Quite confusing, but Service in DDD is not the same as services of Martin Fowler's Service Layer.) Anyway, I agree that IdentityTagRegistrationService is not a good name for explaining architecture of the sample app.
Again, if you include DAO interfaces into domain packages and separate them from DAO implementations in dao package, circular dependencies disappear. This technique is Separated Interface pattern. In this case, DAO interfaces can be regarded as "Repository" of DDD and repositories are residents of domain model in their own rights.
SATO, Tadayosi
www.ouobpo.org
domain contains all domain classes as Vet, Pet a.s.o., service contains interfaces exposed to clients and service.impl contains the actual implementations. So I am forced not to have a domain object in the IdentityTagRegistrationService interface to not create a circular dependency.
If we recognize IdentityTagRegistrationService as a "Service" in the DDD sense, it is also a domain element so no circular dependency occurs. (Quite confusing, but Service in DDD is not the same as services of Martin Fowler's Service Layer.) Anyway, I agree that IdentityTagRegistrationService is not a good name for explaining architecture of the sample app.
Perhaps in the next lower layer the problem becomes more obvious. What if I need to save objects in the logic, or retrieve further objects? DAO interfaces obviously have to expose domain objects. If I had a dependency to the DAO in the domain object then, the circle s perfect.
Again, if you include DAO interfaces into domain packages and separate them from DAO implementations in dao package, circular dependencies disappear. This technique is Separated Interface pattern. In this case, DAO interfaces can be regarded as "Repository" of DDD and repositories are residents of domain model in their own rights.
SATO, Tadayosi
www.ouobpo.org
Great stuff. Let's go further.
by
Eelco Hillenius
That was a good presentation, and indeed how much better does the Java landscape look today. I do hope that Rod and friends someday will take up the defense for OOP in web applications (additionaly with AOP if you want). Clear responsibilies. Encapsulation. All that good stuff should have a place in the web tier like it has in the rest of your software.
Deep trouble
by
John Harby
Check out this link:
www.eia.doe.gov/pub/oil_gas/petroleum/feature_a...
Looks like we've only 40 years worth of oil left. What do we do when we run out?
www.eia.doe.gov/pub/oil_gas/petroleum/feature_a...
Looks like we've only 40 years worth of oil left. What do we do when we run out?
Good summary
by
Rickard Öberg
This was an excellent presentation, that I hope many many people will watch. I wholeheartedly agree with the background description and problem summary, and with the ideas of moving more towards an object-oriented domain model. We have been using this approach in SiteVision for a long time, with AOP as the enabling technology, and have found it to be a good way to avoid the pitfalls Rod outlines.
That being said, I think there are better ways to solve this than to use AOP. But, one step at a time. First everyone must understand the absolutely horriffic situation we are in today, as described in the presentation.
That being said, I think there are better ways to solve this than to use AOP. But, one step at a time. First everyone must understand the absolutely horriffic situation we are in today, as described in the presentation.
Educational Content
.jpg)
Managing Build Jobs for Continuous Delivery
Martin Peston May 24, 2013
Clojure in the Field
Stuart Halloway May 23, 2013
Tuning the Size of Your Thread Pool
Kirk Pepperdine May 23, 2013
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think