Hello all,
I'm new to this group, but a long-time advocate of domain modeling.
I'm now waiting for my "Domain-Driven Design" book to arrive in the
mail.
In the meantime, I wanted to get a feel for how many of you have read
the book "Streamlined Object Modeling" by Nicola et al. It came out
in 2000 or 2001 and is a great book on the mechanics of modeling
domains. I recommend it to anyone that mentions that they're
interested in object modeling, and I would do the same for this group.
It discusses object collaboration patterns, collaboration rules,
services offered by objects, and strategies for enforcing
collaboration rules. It is not language specific, although there are
examples in Smalltalk/Squeak and Java.
Has anyone read this? If so, how similar are the ideas in DDD to
those in SOM?
MatthewAdams
I have!
Hello Matthew, and hello everyone else on the list.
Welcome...I've been monitoring this group for a couple of weeks now, but
have not yet participated - largely because I've not actually finished
reading the book yet. Domain Driven Design the book is fundamentally good,
but I found Streamlined Object Modelling to be more profound. Also Domain
Driven Design talks in detail about object persistence design issues,
without acknowledging that all of those issues can and should be delegated
to an underlying transparent persistence infrastructure (e.g. JDO,
Hibernate). (I'm on the JDO Expert Group, hence this perspective on
persistence which might not be shared by everyone else on the list). As a
result a lot of Domain Driven Design deals with persistence infrastructure
design, and messages to this list discuss lazy loading design patterns, etc.
The book would be figuratively half as thick, and twice as focussed, if it
acknowledged this.
That said I am greatly enjoying Eric's perspective. I am most impressed by
his frankness - I too am guilty of having tried to build a complex
domain-driven object model when a data model would have sufficed and been
more expedient.
Cheers,
RobinRoos
Hah hah! I'm not too surprised to find you here, Robin!
To the group, I also am a member of the JDO expert group, so my take
on persistence is understandably pro-JDO. I have used ODMG's Java
binding as well, so I am pretty well-versed in object persistence.
Nonetheless, while object persistence is important, I would prefer to
see more people spend time creating better models to persist. It is
unfortunate that deficient persistence mechanisms have been the norm
for so long, forcing onto the back burner the pursuit of better
object models only because they could not easily be persisted.
I am particularly interested in the group's opinion on overcoming the
fairly common phenomenon of development organizations that either pay
only lip service to object modeling, never actually pursuing it
beyond analysis to design and implementation, or that don't even
bother with object oriented analysis.
MatthewAdams
Hi Matthew,
I haven't read this or known of its existence, but I'll give it a shot - thanks
for the pointer. Jill Nicola is a longtime associate of Peter Coad's. I tend
to read stuff from the Coad camp because he's made some contributions in the
domain modeling area over the years (see, e.g.,
http://c2.com/cgi/wiki?RoleAndPlayer). But in general I'm put off by his
writing style - I hope Jill Nicola's is better. I also wonder whether his
reductionist tendencies are useful in the end.
FWIW, here are a couple of other book recommendations:
Data and Reality, by William Kent (ISBN 1585009709). Originally published in
1978, before OOPLs were mainstream, but definitely about domain modeling.
Object Design, by Rebecca Wirfs-Brock and Alan Kean (ISBN 0201379430). Does a
great job of describing the true essence of object-oriented design, namely, the
allocation of a system's responsibilities over a set of invented abstractions,
and the trade-offs involved in all that.
RandyStafford
Hi Robin,
Persistence has never been, and probably never will be, truly "transparent".
You yourself said on page 53 of your JDO book that "it is necessary for you to
understand the intricacies of JDO's persistent object model in order to apply
the technology appropriately". I have found the same to be true over the years
for TOPLink, the OMG's Persistent Object Service, and Gemstone (both /S and /J).
Therefore I think any discussion of implementing domain models is nicely
complemented by discussion of how to persist domain models. Domain Driven
Design devotes part of one chapter, 12 pages in all, to the underlying
infrastructural concept of Repositories, and to discussion of relational
persistence of domain models. Its detailed talk of Entities, Value Objects, and
Aggregates is not to do with persistence; it is to do with design and
transactional integrity.
I hope discussion continues on this list of both persistence patterns and
analysis patterns. Both are equally important when it comes to designing and
implementing domain models.
Regards,
RandyStafford
I have to agree with you Randy on this topic. I dont think we could
ever build software and be agnostic to persistence. I also feel
Robins comments while subjective, are a little harsh on Erics book.
interestingly, I find Erics book more profound than Streamlined
Object modelling. I found SOM too interested in the separation of
analysis and design, which is something Eric tries to dispell - the
two models shouldnt be split in a pure domain model. I was actually
disappointed in SOM, but maybe I just didnt like the style.
NickRobinson
Hi,
I too have been monitoring this list for a little while,
Robin/Matthew nice to see you have joined...I'm also a JDO-pro person
on the JDO expert group...amazing how we have all gravitated to this
list???
Anyhow, I agree that transparent persistence is a utopia that JDO
doesn't completely fulfill...however it comes as close as anything
I've seen to date and certainly saves having to deal with O/R mapping
patterns myself and therefore simplifies my life. Some of the earlier
discussions on lazy loading, pre-fetching and how to integrate a
repository into the domain model (getters/setters) all go away with
JDO...note I too haven't finished Eric's book so I can't claim to be
an expert on the non-JDO side of things you are all discussing just
yet, so don't flame me too badly, but I did feel that a tool like JDO
really helps those of us that like domain models and are using
Java...doesn't do much for the .NET or C++ side of things I'm afraid.
Cheers
Keiron
Keiron,
To help us non-Java people, could you explain how repositories, factories and
lazy loading
actually works in JDO? I havent got a clue and it would really help.
Thanks,
NickRobinson
I'll try to give it to you in a nutshell, highly
glossed over:
Using JDO, you author your java classes as you
normally would. Then, you create a JDO metadata file
(xml format) that identifies which classes in your
model are persistent, the class of elements in other
classes' collections, the mapping to your datastore,
and other things. Next, you run a JDO enhancer over
your javac-compiled class files, passing it your
metadata. The enhancer adds enough bytecodes for your
persistent classes to implement an interface called
PersistenceCapable, which is used as a standard
interface to hook into the JDO provider. Once you've
compiled and enhanced, code to actually create
JDO-persisted objects that are brand new looks like
this:
import javax.jdo.*;
// ...in some method of some class
PersistenceManagerFactory pmf = ...;
// depends on environment how you get a PMF
PersistenceManager pm = pmf.getPersistenceManager();
Transaction txn = pm.currentTransaction();
txn.begin();
MyThingy thingy = new MyThingy();
thingy.setDoodle(5);
MyThingamabob bob = thingy.createMyThingamabob(2);
bob.setWhatchamacallit(18);
MyThingamajiggy jiggy = bob.createMyThingamajiggy(3);
jiggy.setDoodlewhacker(23);
pm.makePersistent(thing);
// above call makes all reachable persistent-capable
// objects persistent in underlying datastore upon
// commit
txn.commit();
// actually commits all changes using underlying
// datastore's transaction
|
Code to make changes to an existing thingy looks like
this:
import javax.jdo.*;
//...stuff
PersistenceManagerFactory pmf = ...; // depends
PersistenceManager pm = pmf.getPersistenceManager();
Transaction txn = pm.currentTransaction();
txn.begin();
MyThingy thingy = ...; // use Query & JDOQL to find
thingy.setDoodle(10);
MyThingamabob bob = thingy.getBob();
bob.setWhatchamacallit(48);
// lazily loads MyThingamabob instance
bob.getJiggy().setDoodlewacker(67);
// lazily loads MyThingamajiggy instance
txn.commit();
// above call causes all changes in object state to
// be committed in datastore
|
It's pretty simplified, but not far off the mark.
Does this give you an idea?
MatthewAdams
Matthew thats cool!
So, am right in assuming the PersistenceManager, the Transaction etc are part
of the JDO
framework and you didnt have to write any of those classes? So the key benefits
of this is that
irrespective of whether you are using a DDD domain model or not, you dont have
to hand craft some
key framework pieces. I can definitely see the benefit of JDO now.
But I think DDD when it talks about Repositories for example, is one level
above. The fact a DB
is used seems to be irrelevant - it could be an XML file, a text file or indeed
a network pipe.
But fundamentally, the model is rich because it isnt suffering from noise - is
this a reasonable
statement?
Thanks Matthew,
NickRobinson
Absolutely. The whole benefit of JDO is that you are,
to a large degree, encapsulated from the details of
persistence, focusing instead on the logic in your
objects. Your underlying datastore could range from
an in-memory database to a relational database to an
object database to an xml file to a flat file to an
SAP R/3 system to a CICS system to...well, you get the
idea. In my ever so humble opinion, it's as close to
the holy grail of transparent persistence that you can
achieve today. When you combine JDO with good object
orientation, and carefully consider some other things
with respect to enterprise architecture, you can
absolutely rock and roll.
You are correct in that PersistenceManagerFactory,
PersistenceManager, and Transaction are not something
I had to write -- they come with the jdo.jar.
Robin Roos has a free PDF available of his book, "Java
Data Objects". See his site,
http://www.ogilviepartners.com for how to download it.
It's a really good introductory book on JDO (I ought
to know -- I reviewed it!). There are getting to be
several JDO books out there now. Look for authors
Robin Roos, David Ezzio, Craig Russell, David Jordan,
and others that I'm forgetting as I type this
(apologies to them in advance).
MatthewAdams
That is cool Matthew, and yeh it does like being close to the holy grail. I can
see your points
about persistence. Given all this, would you say that the DDD book wastes time
talking about
Repositories, Proxies, Lazy Loading etc? - I am not trying to cause an argument
btw. I think your
answer would be that such a discussion is less relevant to Java people using
JDO. But not
everybody uses JDO, or indeed any framework for persistence for various reasons.
Not only that, I
believe its the principles that Eric describes in why the repository is used the
way it is that
brings the value.
It is clear JDO brings a lot to the table, and the domain objects remain as pure
domain objects
and (not being a Java guy this is guessing) the persistence stuff would sit in
an upper layer
(application/controller)? I do like that idea, because ultimately I can DDD
with less effort on
problems orthogonal to building the domain model. But, I still feel that the
reasons and
prinicples described as the motives for using a Repository outweigh the
redundancy in say the JDO
world. The reason I feel this, is that irrespective of the environment, moving
towards Domani
concepts rather than technical concepts is what we strive for - ok a Repository
isnt a core domain
concept, but the beauty is in the motivation.
What do you think?
NickRobinson
> Given all this, would you say
> that the DDD book wastes time talking about
> Repositories, Proxies, Lazy Loading etc?
>
I don't know -- I'm still waiting for the book to
arrive!
[snip]
> It is clear JDO brings a lot to the table, and the
> domain objects remain as pure domain objects
> and (not being a Java guy this is guessing) the
> persistence stuff would sit in an upper layer
> (application/controller)? I do like that idea,
> because ultimately I can DDD with less effort on
> problems orthogonal to building the domain model.
>
The transactional control of the objects is in an
upper layer, yes. Finding objects via query could be
in both, depending on where you wanted to draw the
line.
> But, I still feel that the reasons and
> prinicples described as the motives for using a
> Repository outweigh the redundancy in say the JDO
> world. The reason I feel this, is that irrespective
> of the environment, moving towards Domani
> concepts rather than technical concepts is what we
> strive for - ok a Repository isnt a core domain
> concept, but the beauty is in the motivation.
>
> What do you think?
>
The domain concepts themselves are more important than
the technologies used to manifest them at any given
time. If the tools and technologies are expressive
enough so as not to introduce orthogonal artifact,
your domain model is very portable.
Gee, that almost sounds quotable, yes? :)
MatthewAdams
> > It is clear JDO brings a lot to the table, and the
> > domain objects remain as pure domain objects
> > and (not being a Java guy this is guessing) the
> > persistence stuff would sit in an upper layer
> > (application/controller)? I do like that idea,
> > because ultimately I can DDD with less effort on
> > problems orthogonal to building the domain model.
> >
> The transactional control of the objects is in an
> upper layer, yes. Finding objects via query could be
> in both, depending on where you wanted to draw the
> line.
Ok, that makes sense. How does lazy loading fit in with JDO? (I know this
isnt a Java/JDO forum, but I want to see the world from the JDO perspective
because its affects on a domain model are relevant).
> > But, I still feel that the reasons and
> > prinicples described as the motives for using a
> > Repository outweigh the redundancy in say the JDO
> > world. The reason I feel this, is that irrespective
> > of the environment, moving towards Domani
> > concepts rather than technical concepts is what we
> > strive for - ok a Repository isnt a core domain
> > concept, but the beauty is in the motivation.
> >
> > What do you think?
> >
> The domain concepts themselves are more important than
> the technologies used to manifest them at any given
> time. If the tools and technologies are expressive
> enough so as not to introduce orthogonal artifact,
> your domain model is very portable.
>
> Gee, that almost sounds quotable, yes? :)
>
8-) Not only is the model more portable, but noise through technical
dependance is reduced from the domain, making the understandability (based
on the ubiquitous language) that much more riche and valuable.
NickRobinson
> Ok, that makes sense. How does lazy loading fit in
> with JDO? (I know this
> isnt a Java/JDO forum, but I want to see the world
> from the JDO perspective
> because its affects on a domain model are relevant).
>
Through enhancement, JDO intercepts field accesses
(primitive and reference fields) and determines
whether or not the item needs to be retrieved. If it
does, JDO retrieves it; else it's already there.
There is no lazy loading code exposed in the domain
model either to model authors or model client authors.
Further, you can specify what is and is not part of
the default fetch group in JDO1. In JDO2, you will be
able to specify named fetch groups; the idea is that
different fetch groups will apply depending upon the
current use case.
MatthewAdams
Matthew Adams comments about books on JDO:
> Look for authors Robin Roos, David Ezzio, Craig Russell, David Jordan,
> and others that I'm forgetting as I type this
> (apologies to them in advance).
The others are Keiron McCammon, Sameer Tyagi, Heiko Bobzin and Matthew
Vorbuger who all collaborated on "Core Java Data Objects".
Kind regards
RobinRoos
Hello Everyone
Each person has their own perspective from which they view new developments.
Each person that reads a new work such as DDD evaluates the material as it
applies to their background, their current work, their vision for the
sector, their "perspective". At least that's how I understand my own
learning process, and it will be more true or less true for others.
My perspective when approaching DDD is a growing view that transparent
persistence mechanisms, such as JDO and Hibernate, allow us to finally
concentrate on the domain object model; that most business logic belongs in
the domain model; that infrastructure should largely exist to support the
operation of the domain model and "client" applications' access to it; that
building behaviourally rich domains is a rewarding exercise, both personally
and professionally, and yields software which is more flexible to changing
application requirements than approaches that seek unilaterally to divorce
state from behaviour in the name of "separation of concerns".
My "perspective" on transparent persistence with JDO leads me along a line
of architectural thinking which sees the bulk of back-end application design
going into the domain objects (POJOs with no dependency on complex component
interfaces; JDO support is provided after the classes have been compiled).
The application server, when present, delivers container-provided services
such as remote synchronous and asynchronous access (Stateless Session and
MessageDriven EJBs which themselves are usually very "thin" and merely find
domain objects and invoke their services) and container-demarcated
distributed transaction capabilities (CMT & JTA).
My assimilation of object oriented design techniques has taken a reasonably
Coad-based path (as in Peter Coad, the author). Just when I was finding the
short-comings of the Domain Neutral Component (which I colloquially refer to
as "the mother of all patterns"), Matthew Adams introduced me to Streamlined
Object Modelling (SOM). JDO is not an end in itself, but is the enabling
technology that allows us in the Java world to do all this good Object
stuff, unconstrained by persistence infrastructure. I now regularly use and
occasionally teach the principles of SOM and the collaboration patterns it
describes. Martin Fowler suggested I read DDD after attending a
presentation I gave concerning SOM at the JAOO conference in Denmark two
months back.
As I mentioned I'm half-way through DDD. I have greatly enjoyed Eric's
discussion of the Ubiquitous Language, and his examples of its benefit in
real object modelling scenarios. The developer & domain expert
"conversations" are great! I also strongly agree with his premise that the
domain is very important, tempered by his warning that some applications do
not actually need a domain object model. Where I'm at at the moment is
trying to get to grips with the concepts of Entity and Specification, from
my particular perspective. I haven't quite worked out why the term Entity
does not apply to all persistent objects (at least all non-dependent
persistent objects). I have difficulty seeing how to apply "Specification"
to a world where data is found by JDOQL. That doesn't mean I disagree with
the concepts or with the design; I'm trying to position them in terms of
implementation on a particular architectural topology an infrastructure. As
far as Lazy Loading goes, in a JDO world I just navigate references and
objects are retrieved from the database eagerly or lazily according to
configuration settings. After all, these are performance techniques which
are orthogonal to the domain's functional design.
In conclusion, thanks to all who have commented. From my perspective some
of the book's content is not relevant. But my perspective is very
particular. I must bear in mind that not all Java developers use JDO (yet!)
and not all developers use Java. I am thoroughly enjoying DDD, and look
forward to ongoing debate with this group.
And yes, I do find it interesting that several of the most influential
members of the JDO Expert Group (the specification team, to those unfamiliar
with the Java Community Process) have independently found their way to DDD
and to this group.
Kind regards to you all, Robin.
RobinRoos
I have read SOM and am reading DDD. I look at the association
patterns in SOM to be *one* mechanism to contemplate candidate
classes (especially entities) that become part of the domain model.
For example, SOM has an association pattern for events and things.
In the DDD cargo example, this pattern may have helped me determine
the importance of the Handling Event and its relationship to Cargo
(as Handling Event is a transaction that involves Cargo). However,
I still may have been faced with the Eric's circular reference
problem, which is a design and packaging issue. Without considering
the SOM patterns from a DDD perspective, IMO, one could end up with
lots o' bidirectional relationships.
That said, here are some of the tools I would use to help build a
model:
* SOM, which, again can help quickly identify classes that may be
appropriate to the domain.
* Refactoring (perhaps classes that I identified through SOM)
* Analysis Patterns
* Other stuff mentioned in DDD that I haven't got to yet
In summary, I don't see SOM and DDD as competitors. I would use
whatever tools are appropriate and frame all my efforts within the
perspective of DDD.
ChrisGardner
I think that is a very good point. SOM brings value to the table along with the
other tools you
mention. For some reason, if I had to compare the two in terms of how much
value I felt I had
achieved from reading the two books (SOM and DDD), then for me DDD provided more
insight from a
doman modelling perspective. But like you say, they will complement each other,
and when the
second SOM book comes out I am sure that will be another good step towards
rounding the edges of
the topic of domain modelling.
NickRobinson
Matthew,
One of the things I am interested in is providing a different datastore for each different type of DomainObject. Most O/R frameworks do not allow this as the datastore is globally set, how does JDO handle this?
JoshKnowles
JDO currently does not address references across PMFs,
which is essentially what you're asking it to do, but
that doesn't mean you couldn't work around it.
Note: this would not be considered a normal use case
for JDO right now.
If your domain objects had no references to other
domain objects of different types, well, I wouldn't
say that you had much of a domain model, but you could
do this in JDO without any issues.
If domain objects in your model have references to
other objects of differing types, you would have to
store a string object id, given by the result of
PersistenceManager's
getObjectID(domainObject).toString(). Then, when an
object is requested from another domain object, you
would use the appropriate PMF to get a PM, then find
the object by the string ID (there are convenient ways
to do this in JDO), then return a reference to the
requested object.
MatthewAdams
Hi Matthew, Josh
I refer to this capability, the transparent navigation of references from an
instance of one class of object which lives in one datastore to an instance
of another class of object which lives in another datastore, "JDO
Interoperability". This is they key item on my agenda for JDO 3.0 - after
we've completed the tranche of features for JDO 2.0. Note that the two
datastores could potentially be of completely different paradigms, e.g.
ODBMS, RDBMS, XML, etc. As Matthew points out this requires the two objects
to be managed by different persistence manager factories (PMF), and is not a
targeted use case right now.
With JDO today we can defer deployment decisions, such as whether the
datastore will be ODBMS or RDBMS, whether there will be an application
server or not, etc., because the domain objects we design and build are
unaffected by such decisions. With a good interoperability spec in place we
could design and build domain object models deferring even the decision
about which of several datastores will host instances of each class,
although the pragmatic use-case is actually to manage data which already
resides in different places with no more complexity than if they were all in
the same place. Once again JDO is not an end unto itself, but an enabling
technology which facilitates better designs and a more pure object-oriented
view of the domain regardless of datastore. But please don't hold your
breath for the interoperability spec!
Kind regards,
RobinRoos
Hi Nick, you wrote:
> I have to agree with you Randy on this topic. I dont think we could
> ever build software and be agnostic to persistence.
I've been successful abstracting persistence with the patterns and framework I
use, but sometimes a previously-untried persistence mechanism forces adjustment
of the interface between the domain layer and the persistence layer. More on
that in an upcoming post.
> I also feel
> Robins comments while subjective, are a little harsh on Erics book.
I concur. I hope Eric wasn't too insulted by Robin posting his opinion on
Eric's own mail list that some other book was more profound. Robin, thanks for
tempering in your subsequent posts. It's great to have your participation! I'm
very interested in JDO and I look forward to many insightful exchanges.
> interestingly, I find Erics book more profound than Streamlined
> Object modelling. I found SOM too interested in the separation of
> analysis and design, which is something Eric tries to dispell - the
> two models shouldnt be split in a pure domain model. I was actually
> disappointed in SOM, but maybe I just didnt like the style.
For my money, Eric's book is unique, seminal, and among the most incisive and
important books ever written about the essential traditions of object-oriented
software design. It's been highly praised, inside the front cover, by several
of the most influential thought leaders in our profession - people who've
advanced the tradition Eric describes, and launched several other dominant
contemporary movements, such as patterns and agile methods. One of those
people, Martin Fowler, told me about Eric's project 15 months ago, and I've been
eternally grateful ever since first reading the manuscript. I'll reserve
judgement on SOM until after I've read it - I've ordered a copy - but Eric has
set the bar very high.
Best Regards to All,
RandyStafford
> It is clear JDO brings a lot to the table, and the domain
> objects remain as pure domain objects
> and (not being a Java guy this is guessing) the persistence
> stuff would sit in an upper layer
> (application/controller)?
Actually a lower layer, namely the persistence layer, as I wrote in Chapter 7 of
EJB Design Patterns (John Wiley & Sons, 2001). I've attached my final draft of
that chapter that I sent to Floyd Marinescu and the publisher, which describes
an approach that I've been using to persistence for four years and six J2EE
applications now, that features essentially a combination of the Facade and
Strategy patterns.
If you have the book, you'll notice that my description of my approach was
deleted from the final copy. Floyd said at the time (3Q01) that he didn't have
much experience with POJOs, so he couldn't really appreciate the approach, and
he was worried that the readership wouldn't appreciate it either (seeing as how
the book was about EJBs and all). OK, whatever.
Anyway, the approach works, and a framework using the same patterns can probably
be written in any OOPL (Nick). Mine's written in Java. It assumes that
transactions are controlled by layers higher than the persistence layer (e.g.,
the service layer), which control invariably requires interaction with
persistence-layer objects (e.g., sessions/connections, units of work, etc.).
Since I've always used my framework in the context of J2EE application servers
with container-managed transactions, my service-layer application code doesn't
actually encode those interactions - they're in the realm of the "container" or
"glue" between the container and the persistence mechanism. But I know how I
could still keep them out of application code even if I wasn't using an
application server: I use the Execute Around idiom (see Kent Beck's Best
Practice Smalltalk Patterns) in my service-layer methods, and I'd just have the
methods that are invoked around the execution delegate to a configured
transaction control policy.
The Facade is named PersistenceLayer, and it props up a "CRUD" API whose
implementation is delegated to a configured PersistencePolicy (the Strategy).
Over the years I've written about six different PersistencePolicies - one for
GemStone/J, one for a home-grown O/R mapper written within GemStone Professional
Services, one for in-memory example data, one for a mechanism that persisted
domain objects using XML documents over JMS, and two for TOPLink (one that used
UnitOfWork's "merge" algorithm, and one that doesn't). It provides the same
benefits to me that JDO wants to provide, but I've been using it in production
applications since 1999, and I'm still using it today. Someday I hope to write
a JDOPersistencePolicy. I've been successful switching an application's
persistent store by simply re-starting the application with a different policy
class configured (assuming database initialization, of course).
My good friend and esteemed longtime professional colleague Dave Muirhead also
uses it, and he was recently able to switch a complex DDD application from using
an XML database to using O/R mapping in a couple of days (mostly due to
replacing XPath queries). But I'll let him tell you about that.
You might ask what is the relationship to Repositories? It's a good question.
In the application from which this framework was extracted, and in other early
applications to use it, we had some awkwardness around needing
application-specific querying methods on PersistenceLayer and PersistencePolicy.
Nowadays those interfaces are parameterized with Expressions that can be
converted to SQL, or to predicates to select out of in-memory collections, or to
whatever. So that need and awkwardness have gone away, and PersistenceLayer is
application-independent. That is to say, application domain object -type
independent. One of the purposes of Repositories is to provide type-specific
querying behaviors. So it has occurred to me, since reading Eric's book, that
Repositories could sit on top of the PersistenceLayer and adapt to its
interface. Another purpose of Repositories is to provide independence from
persistence mechanism. That would be easy to achieve by delegation to the
PersistenceLayer; probably easier to achieve than by inheriting
mechanism-specific behavior.
I have long hoped, and still hope, to do a proper job of publishing these ideas
someday, in a book. So I would ask that if you use or reference these ideas,
you have the integrity to attribute them to me, citing this posting to the DDD
yahoo group.
Thanks,
RandyStafford
Randy,
Once again your contribution, time and effort serves as inspiration. In the
dialogues we have
had, both public and private, I have always been surprised at how much you try
to make things
clear when the world seems hazy. I will likewise spend as much effort in
reading through this
email again, along with your attachment Randy, thanks!
Best regards
NickRobinson
I definitely share that view. But I have to smile at the use of the word
"finally". Kieron said a similar thing in his post: that JDO comes as close to
utopian transparent persistence as anything he's seen to date.
We were concentrating on the domain model, instead of fighting technology, 15
years ago in Smalltalk. Patrick has already attested to the ease with which
objects were persisted in GemStone/S. I experienced that ease myself as a
GemStone/S customer and user from 1989-1997; it allowed me to focus on my
applications' functionality instead of tedious technical issues (at least until
the Smalltalk VMs that were GemStone clients moved to the middle tier of 3-tier
architectures; see
http://wiki.cs.uiuc.edu/VisualWorks/DOWNLOAD/papers/int_vwgs2.zip, which I
submitted to The Smalltalk Report in 1996, right when it was going out of print
- I hate it when that happens!). Also, did you know that XP was born on a
GemStone/S project? One of the 12 practices of XP is refactoring - and schema
migration in GemStone/S is easier than in any other persistent store I've ever
seen, which eases refactoring a persistent domain model.
We had the same ease in GemStone/J starting in 1998. All you had to do was
create an instance of something, make it reachable from a JNDI node, and commit.
That's it. Done. No mapping, no meta-configuration, no enhancement. No muss,
no fuss. Unfortunately GemStone's VP of Marketing came from ParcPlace Systems,
so BEA and IBM did the same thing to GemStone's market share that JavaSoft had
done to ParcPlace's market share a few years earlier.
And for object populations sufficiently small, it was even easier in Smalltalk
without GemStone: a lot of early Smalltalk applications simply persisted their
objects in the image. A Smalltalk "image" is simply a snapshot of the heap
within a VM, saved to disk. When you start a Smalltalk VM, you don't pass the
name of a class whose "main" method running ultimately causes creation of all
the objects on the heap; instead you pass the name of an image file, which is
re-loaded into memory and contains whatever objects were on the heap when you
last saved the image. So all you had to do was instantiate your class, and save
the image. It doesn't get any easier than that.
Alas, the good old days. It would be nice if JDO or similar could bring them
back, and make them mainstream.
RandyStafford
Randy, for what its worth I'm a long time ODB advocate (I've worked
for Versant for the last 7+ yrs) and JDO is definately born out of
that desire to have a similar level of ease of use and transparency
that ODBs championed (us, GemStone and others). In my opinion it gets
pretty damn close, so close in fact that we are adopting JDO in
preference to our own APIs as the interface to the Versant ODBMS. We
can do that because JDO is as transparent to the developer as our own
proprietary interface is).
Cheers
Keiron
> If there is still a relational database underneath the JDO, I
> must know that. Mapping between those two ways of organizing
> information is a conceptual modeling constraint. Arbitrarily complex
> mapping is just not practical.
Just to clarify this, if you have a pre-existing schema then no matter how
exotic the underlying mapping technology there will be some constraints on
the object model you can build and map to that schema. We do our best to
limit those constraints.
However, if you have no pre-existing schema but are starting with an object
model you wish to persist into a relational database through JDO, we place
no constraint on your model specific to its being stored relationally. Your
JDO implementation will generate a schema for almost anything you can throw
at it.
> Aggregates are a conceptual modeling issue.
The name is not one I've used in this context, but your "Aggregate" concept
is very good. Entities (in entity-relationship modelling days I called
these "Strong Entities") have related classes which express some of their
finer detail, called Aggregates. These objects are dependent upon the
entity and cannot exist before or after the Entity. They can hold
relationships to other entities, but classes outside the aggregation
boundary may only hold relationships to the Entity which sits across that
boundary.
The use of Aggregates and the observance of aggregate boundaries is an
object modelling technique. Once you've built the object model, your
persistence infrastructure must persist it faithfully. JDO has some
features which help you to do this, including (a) notions of Second Class or
Embedded Objects (which can be owned by one and only one First Class Object)
and (b) unmanaged extents - if a class's extent is unmanaged then you can't
query over the extent of all instance of those classes, and Aggregates are
ideal candidates for this. (All Second Class Objects implicitly have
non-managed extents.)
> Let's say the JDO can transparently persist the whole graph of objects
referenced > from a given object. This is very helpful, but an application
needs a model
> that helps define the scope of change in transactions. This is not
> just a relational database issue. The first time I saw explicit
> aggregates applied was in GemStone.
By "transaction" here you're referring to domain objects that represent
transactions, as opposed to datastore transactions, I presume. Aggregates
and their boundaries represent good use of cohesiveness where appropriate
and serve to reduce coupling. Domain classes which represent business
transactions talk to other Entities, and not directly to those entities'
aggregate classes. However there is naturally no need to track database
transaction or dirty object information in a domain model; the pollution of
the model would be counter to the establishment of the ubiquitous language.
> Something like JDO can make repositories much simpler to
> implement, but they still have their conceptual value. They
> encapsulate the technical aspects of queries. They communicate a
> modeling decision about which objects should be entry points into
> the system. (Aggregates also go to that point.) They provide a model
> concept to represent the capability of the underlying framework to
> find objects of a certain type.
It would be easy to implement a Repository on top of JDO, employing the
JDOQL query language to find instances in the datastore in response to
Repository methods each with a particular purpose in mind. In a JDO world
you cannot stop someone from using JDOQL directly to achieve the same end.
The question is whether one approach is better than another, and here I
would suggest there is no black and white.
Using Repository, knowledge about how to retrieve specific instances that
match given criteria is centrally located and centrally managed. To
implement a new query path you must alter the repository. This has
similarities with the Find methods of Entity EJBs.
With direct JDOQL you execute a query with a filter expression that
traverses the persistent object graph to establish whether each candidate
instance should be included in the return. The person writing the filter
must know which fields in the queried objects are persistent and how the
associations between persistent objects are structured. Otherwise you
wouldn't know to write "company.vatDetails.vatNumber=\"12345\"" for a
particular query. Some people liken this to a breach of encapsulation.
The best option may be to define named queries in the JDO configuration
metadata and invoke these by their name; knowledge of query structure is
removed from classes that query for other objects, and centralised into the
metadata. This is a configuration-driven alternative to the coding of a
Repository class. One thing that Repositories can add to this is
compile-time type checking. Now I must re-read the Repository section of
DDD, but my first impression was that they are an unnecessary abstraction if
your approach if from a JDO-based perspective.
> So, as technologies like JDO make it easier to manage persistence,
> it may make it unnecessary to give examples using SQL and
> unnecessary to talk about lazy loading. That would be great. But it
> won't lift the burden of drawing some lines around aggregates, so
> the model isn't one inextricable tangle. And it won't mean that
> models can be detached from the task they are applied to.
Agreed. Very strongly!
RobinRoos
Hi Nick / Randy et. al.
Nick commented:
> I also feel
> Robins comments while subjective, are a little harsh on Erics book.
Randy concurred:
> I concur. I hope Eric wasn't too insulted by Robin posting his opinion on
> Eric's own mail list that some other book was more profound. Robin,
thanks
> for tempering in your subsequent posts. It's great to have your
> participation! I'm very interested in JDO and I look forward to many
> insightful exchanges.
I also hope that Eric took no umbrage, and genuinely apologise if this has
been the case. I am impressed with what I have read (did that not come
through?) and agree that Eric has made a substantial contribution to the
body of knowledge in this important area, and the establishment that this
area is indeed of great importance.
This would also appear to be a good time to make another statement: I am
not trying to hijack this forum with lobbying about JDO. I was genuinely
surprised to meet several fellow JDO experts on this list - we often debate
OOD issues and sometimes SOM, but DDD has not specifically come up in our
other discussions to date. I see JDO as an important enabling technology,
which allows us (those who use it) to focus on domain models unconstrained
by persistence considerations to a much larger extent than before in the
context of JDBC / EntityEJB technology. I will discuss here how JDO
facilitates this and allows us to defer deployment decisions where it is
useful so to do. But there are other places for in-depth JDO-specific
discussion.
(That said, I am about to send 6 messages written off-line, some of which
address specific questions in relation to the JDO-perspective, so I may yet
be judged a hypocrite!)
RobinRoos
> I also hope that Eric took no umbrage, and genuinely apologise if
this has
> been the case.
Don't worry. I was not offended. I want to see a lively discussion
here, including other related ideas such as SOM.
> This would also appear to be a good time to make another
statement: I am
> not trying to hijack this forum with lobbying about JDO.
I think the JDO discussion has been useful. It is relevant exactly
because domain-driven design is so dependent on its frameworks,
programming languages and other infrastructure. So, discussion of
the impact of different persistence technologies on DDD, or how to
use them in a way that supports DDD, or especially the form the
different patterns (aggregates & repositories, for example) take
when using those different technologies are all relevant. Of course,
we wouldn't want to get into extensive discussion of how to use JDO
or how it works, but I wouldn't want to draw the boundaries too
tight. The brief example someone posted seemed to help things along.
It would be nice to have a messaging board that let people drop out
of a thread they weren't interested in(as I said in a new thread),
especially when the traffic starts to increase.
EricEvans
StreamlinedObjectModeling is mentioned on: ThreadView
