Wed Jun 18, 2003 6:15 am
Eric
I enjoyed reading the draft of your book. I might disagree with a few
points, but overall I think it is a valuable contribution to the field.
I wonder if you are aware of the Naked Objects framework? It could be used
to illustrate a lot of your points rather well. You can get it from
www.nakedobjects.org
RichardPawson
P.S. I am just completing my PhD thesis on the Naked Objects Pattern which
is essentially about making the domain model layer the only place where
software is developed. All behaviour is encapsulated on the entity objects
(so there's no need for an 'application' layer) and the UI is merely a
direct reflection of the domain model (i.e. auto-generated). It sounds
like it couldn't work, but it actually works very well. It's the absolute
anithesis of your Smart UI anti-pattern. If you're interested I'd be happy
to send you a copy of the draft
RichardPawson
Richard,
I read your book and found it fit well with work I was doing last fall (got the book at OOPSLA). We took a slightly different approach, but the goal was essentially the same - let the users control their own work.
I am working on my Ph.D. as well, but from the social and philosophical side of the user interface. Would you be willing to share a draft of your thesis? Once mine gets a little farther, I'd be more than happy to do the same if you'd like - it's probably a bit far out for most people.
Thanks,
PamRostal
I'm not working on a book or a Ph.D., so I'm not sure I can
authoritatively join this thread, but I read both these books
recently (concurrently at times) and noticed the overlap of
ideas/practices. I often felt the NO book was a concrete instance of
some of the general ideas in DDD.
I remember the name-collision in my head of the "Smart UI" concept,
since I thought of the Viewer in NO as a pretty-smart-UI, one that
could query objects and discover how and what to display from them.
But since it has no application smarts itself (it just knows who to
ask and how), there is no actual collision. As Richard notes, the NO
Viewer and the DDD "Smart UI" are antithetical. So does that make NO
a DDD anti-anti-pattern? :)
BrettMcHargue
I'm not working on a book or a Ph.D., so I'm not sure I can
> authoritatively join this thread, but I read both these books
> recently (concurrently at times) and noticed the overlap of
> ideas/practices. I often felt the NO book was a concrete instance
of
> some of the general ideas in DDD.
Please do participate. I don't have a Ph.D. either.
I think you are right: Naked Objects is an attempt at a concrete
application of domain-driven design (the idea, as distinct from the
book.) As such, I find it hopeful.
> I remember the name-collision in my head of the "Smart UI"
concept,
> since I thought of the Viewer in NO as a pretty-smart-UI, one that
> could query objects and discover how and what to display from
them.
Yes, as I mentioned in my previous post, maybe I should have called
it Domain-Savvy UI. Too late now. The NO viewers are a UI layer,
with no domain logic. This follows the Layered Architecture. My
worry is about user tasks that don't map conveniently to domain
objects, and the effect that will have on the model.
I think this is related to the Use-Case thread, also.
> Viewer and the DDD "Smart UI" are antithetical. So does that
> make NO a DDD anti-anti-pattern? :)
I don't want to go down that path! :)
EricEvans
I am aware of the Naked Objects framework, but don't know a lot
about it. It is definitely an attempt to drive design from the
domain.
When I read about it, I found it an exciting idea, but I had a few
reservations. The biggest was the idea of generating the UI from the
business objects. I don't think it is the problems that arise in
a "Smart UI". In fact, Naked Objects DOES separate UI from the
business objects, in the form of those generic views, and so on. The
UI in NO is less "smart" in the sense I meant than it is in most of
my designs. (My name Smart UI is ok in the context of my book, but
in a broader context maybe something like "Domain-Savvy UI" would
have been better. A quite generic UI element can be very smart.)
But I think that the UI often needs to be streamlined for user tasks
in a way that doesn't break down as one object--one UI element. (It
would be interesting to have somebody expert in UI design join this
discussion.) Something in the system has to make this reach, and in
NO I'm afraid it will be the domain objects. Perhaps the UI could
reach part way by creation of a specialized viewer. At this point,
my lack of detailed knowledge (not to mention hands-on experience)
of NO prevents me from saying much. But those were the concerns I
had.
EricEvans
Eric wrote:
>My worry is about user tasks that don't map conveniently to domain
>objects, and the effect that will have on the model.
This is a common and very understandable reaction to the Naked Objects
concept. To begin with it seems unlikely that all user actions would map
onto objects, but when you try it out this is much less of a problem than
it seems.
When we first started four years ago, we found ourselves writing 'helper
methods' on some objects, which didn't really naturally belong. But as the
generic capabilities of the framework have been extended, we find the need
for these helper methods has reduced.
A good example is having a method on a Customer object called
CreateNewBooking (for that Customer). This is convenient to the user but
arguably not a natural responsibility of Customer. However, assuming that
there is a bi-directional association between Customer and Booking (as is
usually required) then the latest framework automatically provides the
functionality to create a new Booking ready-associated with the Customer
just by right clicking on the grey 'hole' at the bottom of the collection
of Bookings visible inside the Customer.
Our experience suggests that far from corrupting the model, the discipline
of forcing all user actions to be behaviours on domain objects, forces much
better domain modelling. For example, Dan Haywood and I recently did a
comparative implementation of a four-layer Java application with a Naked
Objects implementation. (We were very rigorous in our technique to avoid
any bias in favour of Naked Objects). Not only was the latter much more
efficient in coding terms, but it also proved much easier to modify than
the conventional 4-layer model (which had an 'application' layer) in
response to unforeseen changes in business requirements. If anyone would
like to see the data on that experiment, please email me direct.
RichardPawson
It is interesting. I like the emphasis on the model, and the
attitude that you refuse to compensate for a weak model with a
complicated application layer. That is a slippery slope, and you
guys are staying far from it. I also think that your UI layer is
very distinct, with little domain logic but a lot of display
capability built in. (So maybe your objects have some underwear on,
anyway.)
I don't have either real expertise in UI design or hands-on
experience with Naked Objects, so I can't really reach conclusions.
I haven't even had the experience of using an app written in naked
objects. (I have used earlier domain-object oriented UIs that did
not work well, but I won't tar you with that brush. It sounds like
you're concious of those pitfalls, at least.)
I hope there will be multiple, successful approaches to domain-
driven design. I am glad this approach is being tried, and it sound
like it is still evolving and being improved. I'll try to learn a
bit more about it when I get a chance.
EricEvans
IllustratingYourIdeasWithNakedObjects is mentioned on: ThreadView
