Sun Jun 22, 2003 1:19 pm
Hi,
I am a newbie to the world of domaindriven.
I have come across a vendor statement to the effect that J2EE does not offer much support to the domain-centric type of applications.
Should this be considered a true statement ?
HenrykMozman
I'm afraid that is a complicated question. I suppose the short answer is
yes, domain-driven designs are done in J2EE, although it is a complicated
framework, and you could easily imagine a more supportive one. In practice,
domain-driven projects using J2EE pick and choose the features of the
framework that they really need. One project I worked with chose not to use
Entity Beans, but got a lot of benefit from Session Beans. The J2EE folks
even have a pet name, "POJOs" (Plain Old Java Objects), for elements of
their design for which they choose a light-weight implementation.
Typically, these are encorporated into the framework at a larger
granularity, such as an entity bean that provides a large-grained service.
Could you quote more of the statement that prompted the question?
EricEvans
Eric,
Thanks for the explanation.
The statemetn that prompted this question I found it in the following document:
http://www.austinjug.org/media/Keiron_Domain_Model_Centric.pdf
HenrykMozman
Thanks for the link. I looked through it. It is a slide presentation,
and so it is risky to interpret without the having heard the talk
that goes with it. With that caveat, I'll venture a few comments.
Their statement that J2EE doesn't provide much support for domain-
driven design has the heading "A Contentious Conjecture". And then
they spend the rest of the talk telling how to do just that. Since
J2EE came along, people have been experimenting with ways of making
it work with models. This presentation describes one approach which,
if I interpret the slides correctly, is basically:
- Use J2EE to implement coarse-grain components (specifically,
stateless session beans)
- Use plain old Java objects to implement the domain model.
- Let the components call the Java objects to delegate the actual
logic that is being requested of them by the client.
This is becoming a pretty main-stream view. Once people got used to
the idea of not relying on J2EE to implement their domain objects,
things did clarify.
Actually, it looks like it was probably a good presentation.
EricEvans
I don't think it should be considered a true statement that "J2EE
does not offer much support to the domain-centric type of
application".
First of all, J2EE is much bigger than EJB. You can build a J2EE app
without using any EJBs.
That said, the main redeeming value of EJB (IMHO) is hooking the
transaction coordinator from stateless session beans.
I agree with Eric that the emergent pattern is a layer of services
implemented as stateless session beans, coordinating the
responsibilities of POJO domain objects. That pattern was actually
documented by Alistair Cockburn way back in 1996 or so, pre-dating
EJB.
I'm also glad to see the recognition by Eric (and Rebecca Wirfs-
Brock, in her recent and excellent book Object Design) that there are
certain system responsibilities that just don't fit well when you try
to allocate them to domain objects. In my experience those
responsibilities often have to do with interacting with external
systems. I'm grateful that the word "service" has been accepted into
the vocabulary to describe the kind of object to which such
responsibilities are allocated, and I used it in my chapter in Martin
Fowler's Patterns of Enterprise Application Architecture.
I could pick a couple of nits in the Versant presentation, but
overall I agree it is pretty good; pretty well on the money. One
thing, though: it's bizarre to see the use of the word "Controller"
in the layer of architecture where the Versant presentation shows it -
see
http://c2.com/cgi/wiki?WhatsaControllerAnyway. I'd be sorely
tempted to refactor that "AccountController" out of the architecture,
and reallocate its responsibilities to the services above it and/or
the domain objects below it.
RandyStafford
Just using session beans for the distributed services, and POJOs for the
domain model does simplify the development, and serializable POJOs solve
the "entity" problem for distributed access to data. However, there are
some problems that could result from this approach:
1. The POJOs may introduce too much data throught the services to the
client resulting in security and performance problems.
2. The data mapper layer between the POJOs and the data sources has to be
built somehow.
3. Transactions my involve data sources that span multiple physical
database systems and/or legacy applications.
Addressing these problems can be done by a combination of CMP beans (with
local interfaces only) to do the domain/data source mapping, and using
DTOs (Data Transfer Objects) to separate the domain from the distributed
data requirements. CMP beans provide additional container managed security
and enable transactions across multiple data sources. The DTOs enable
separation of the domain from the client data needs (throught the
services) essentially allowing views of the domain data that can be
bundled for distribution, and subset and restrict the data for security
and performance reasons.
The services and client requirements indicate what DTOs are needed.
Generic, reflective, metadata-driven implementations can reduce the need
to replicate the domain model in the DTOs reducing maintenance costs.
Other things entity beans provide that might be of interest are load
balancing, read-ahead, access intents for isolation, etc. These can also
be provided by COT data mappers.
JimAmsden
Hi,
A friend of mine pointed me to this group after seeing the
presentation that I have given at various user groups being
discussed. Glad you felt some of the points I presented were useful.
<rstafford@i...> wrote:
> I don't think it should be considered a true statement that "J2EE
> does not offer much support to the domain-centric type of
> application".
Yes, true...I'm really refering to EJB ;-))
> That said, the main redeeming value of EJB (IMHO) is hooking the
> transaction coordinator from stateless session beans.
>
Absolutely.
> I could pick a couple of nits in the Versant presentation, but
> overall I agree it is pretty good; pretty well on the money.
Thanks.
> One
> thing, though: it's bizarre to see the use of the word "Controller"
> in the layer of architecture where the Versant presentation shows
it -
> see
http://c2.com/cgi/wiki?WhatsaControllerAnyway. I'd be sorely
> tempted to refactor that "AccountController" out of the
architecture,
Indeed, I've been presenting this for the last 2 years or so and its
changed along the way. When I present I typically refer to this layer
as the serices layer, I really need to get around to updating the
presentation also. I do believe in keeping the majority of business
logic outside of my EJBs themselves however, hence the Contoller
classes, this allows me to test outside of the component architecture
(to a fair degree) and deploy with different architectures
(Servlet/EJB/RMI).
Cheers
Keiron
Jim wrote:
> Just using session beans for the distributed services, and
> POJOs for the
> domain model does simplify the development, and serializable
> POJOs solve
> the "entity" problem for distributed access to data. However,
> there are
> some problems that could result from this approach:
>
> 1. The POJOs may introduce too much data throught the services to the
> client resulting in security and performance problems.
Not in an undistributed architecture, where HTTP is the communication protocol
into the VM where the POJOs live.
> 2. The data mapper layer between the POJOs and the data
> sources has to be
> built somehow.
In my opinion the data mapper is better bought than built. There are plenty of
solutions available in the commercial and open-source markets, and building one
is not the value-add of the typical consuming organization.
> 3. Transactions my involve data sources that span multiple physical
> database systems and/or legacy applications.
Yes, but that doesn't automatically dictate an entity bean -based solution. The
trade-off is bigger than that. There are other ways to address that issue, in
data mappers and/or application code, that don't have the negative consequences
of entity beans.
> Addressing these problems can be done by a combination of CMP
> beans (with
> local interfaces only) to do the domain/data source mapping,
Our domain model has 713 TOPLink-mapped Java types. If it was implemented with
entity beans instead of POJOs, we would have to maintain at least 4X the number
of source files (component interface, home interface, deployment descriptor - 5X
if we were using the "business interface" pattern). Not to mention all the
deployment issues (EJB "compilation", jars, etc.). Not to mention all the
runtime performance overhead (maybe more heap demand than with POJOs, certainly
more logic to execute for transaction hooks, security hooks, etc.). I don't
need that. I don't want that.
> CMP beans provide additional container
> managed security
> and enable transactions across multiple data sources.
[...]
> Other things entity beans provide that might be of interest are load
> balancing, read-ahead, access intents for isolation, etc.
That's the standard JavaSoft Kool-Aid, but it's YAGNI for me.
> and using
> DTOs (Data Transfer Objects) to separate the domain from the
> distributed
> data requirements. ... The DTOs enable
> separation of the domain from the client data needs (throught the
> services) essentially allowing views of the domain data that can be
> bundled for distribution, and subset and restrict the data
> for security
> and performance reasons.
[...]
> The services and client requirements indicate what DTOs are needed.
> Generic, reflective, metadata-driven implementations can
> reduce the need
> to replicate the domain model in the DTOs reducing maintenance costs.
If there must be distribution in the architecture between the "client" and the
domain model, then I agree some type of DTO solution is necessary. But I'm a
big fan of undistributed architecture, and a big believer in Martin's First Law
of Distributed Object Design, because my experience has been that distributing
domain models between process address spaces (whether due to O/R mapping, or
DTOs) is difficult and painful. It introduces duplication unless the domain
object classes themselves are used as DTOs, and Assemblers can become very
complex, especially for large complex aggregations involved in update use cases.
RandyStafford
Jim-
What Randy said....
(and then another comment inline below)
--- In domaindrivendesign@yahoogroups.com, "Stafford, Randy"
<rstafford@i...> wrote:
> Jim wrote:
>
> > Addressing these problems can be done by a combination of CMP
> > beans (with
> > local interfaces only) to do the domain/data source mapping,
>
> Our domain model has 713 TOPLink-mapped Java types. If it was
implemented with entity beans instead of POJOs, we would have to
maintain at least 4X the number of source files (component interface,
home interface, deployment descriptor - 5X if we were using
the "business interface" pattern). Not to mention all the deployment
issues (EJB "compilation", jars, etc.). Not to mention all the
runtime performance overhead (maybe more heap demand than with POJOs,
certainly more logic to execute for transaction hooks, security
hooks, etc.). I don't need that. I don't want that.
>
> > CMP beans provide additional container
> > managed security
> > and enable transactions across multiple data sources.
> [...]
> > Other things entity beans provide that might be of interest are
load
> > balancing, read-ahead, access intents for isolation, etc.
>
> That's the standard JavaSoft Kool-Aid, but it's YAGNI for me.
I'm interested in whether you (or anyone) can cite actual examples of
a complex domain model being mapped into a complex database schema
using CMP.
If you do have such an example, please characterize the domain model
and the database schema so that we can understand its degree of
complexity. You choose the metrics.
`Dave Muirhead`
I also agree with everything Randy said. I was just trying to point out
what CMP beans might add for value in certain (perhaps infrequent)
situations.
JimAmsden
Dave wrote:
> I'm interested in whether you (or anyone) can cite actual examples of
> a complex domain model being mapped into a complex database schema
> using CMP.
>
> If you do have such an example, please characterize the domain model
> and the database schema so that we can understand its degree of
> complexity. You choose the metrics.
If I may add an additional qualifier, how about in production over many
releases, with good performance, scalability, availability, and development
productivity.
Thanks,
RandyStafford
Hi Kieron, thanks for posting to the broader group. You wrote:
> > I could pick a couple of nits in the Versant presentation, but
> > overall I agree it is pretty good; pretty well on the money.
>
> Thanks.
No problem - we object database guys have got to stick together ;)
> > One
> > thing, though: it's bizarre to see the use of the word "Controller"
> > in the layer of architecture where the Versant presentation shows
> it -
> > see
http://c2.com/cgi/wiki?WhatsaControllerAnyway. I'd be sorely
> > tempted to refactor that "AccountController" out of the
> architecture,
>
> Indeed, I've been presenting this for the last 2 years or so and its
> changed along the way. When I present I typically refer to this layer
> as the serices layer, I really need to get around to updating the
> presentation also. I do believe in keeping the majority of business
> logic outside of my EJBs themselves however, hence the Contoller
> classes, this allows me to test outside of the component architecture
> (to a fair degree) and deploy with different architectures
> (Servlet/EJB/RMI).
The funny thing is, the previous architects at my company had that pattern -
there are a bunch of classes in our codebase, whose names end in Controller, in
exactly that layer of architecture (between services and domain). IMHO they're
worse than useless. I'm on a campaign to rid the codebase of them. When I saw
them in your presentation, I got to wondering whether there was some precedent
for this kind of thing. Have you ever seen them anywhere else? I would be less
surprised to see abstractions named "Controller" between the Presentation and
Services layers, regardless of whether the connotation is Jacobsonian or
Smalltalkesque.
Best,
RandyStafford
Fri Nov 7, 2003 3:06 am
Hello All
I've been reading some of this list's archived messages. In June,
Henryk Mozman initiated a brief thread titled "Domaindrive and J2EE"
which considered J2EE-based architectural views similar to those I
have expressed here this week. His thread was based on an archive of
a presentation given to the Austin JUG.
The Austin JUG has reorganized their site and it took me a while to
find the presentation slides; the new URL is:
http://austinjug.org/eDocuments/Keiron_Domain_Model_Centric.pdf
And if Henryk or anyone else has questions on the approaches which
this presentation advocated, its author Keiron (not Kieron) McCammon
is evidently reading this list!
RobinRoos
DDDandJ2EE is mentioned on: ThreadView
