Rod Johnson: Are we there yet?
Recorded at:
- Share
-
- |
Read later
My Reading List
Bio
Rod is the father of Spring. The Spring Framework open source project began in February 2003, based on the Interface21 framework published with Rod's best-selling Expert One-on-One J2EE Design and Development. Rod is one of the world's leading authorities on Java and J2EE development.
JAOO is the premier European developer conference on software technology, methods and best practices. The conference presents in-depth presentations and tutorials by researchers, engineers and trend-setters in software engineering and technology.
Circular dependencies?
by
Oliver Gierke
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
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
Deep trouble
by
John Harby
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
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.
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