hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <>
Subject RE: Designing with Hivemind best practices
Date Tue, 03 May 2005 12:10:31 GMT

As for your comments on the article, yes the UserFactory service was a bit
too "thin."  But, I wouldn't necessarily suggest removing it.  I structured
the code for the article based upon principles from the book Domain Driven
Design: Tackling Complexity in the Heart of Software by Eric Evans.  In the
book, Evans prescribes the use of entity "factories" to hide the
complexities of object creation.  In my example, though, there wasn't much
complexity to hide.  Factories are supposed to be used when creating a
single "aggregate" object involves creating many other objects.  The logic
doesn't belong inside the constructor.  Nor does it belong inside the client
code which needs the object to be constructed.  But, it does belong inside
the "domain."  So, factories are introduced.  As I said, my example didn't
really require the use of a factory, but the User class would be an
"aggregate" in a real system and creating one would involve creating other
objects (Roles, Addresses, etc.).  If you design that way from the
beginning, you don't have to refactor later when you need a factory (finding
everywhere you used the constructor directly).  Using the factory, however,
did make my unit testing easier.  I merely had to tell my mock factory which
object to return, avoiding the use of "argument matchers" and the like.

As for your other stuff, it sounds rather cool.  The trick would be making
your installer service know that the application has already been installed,
across restarts.  You could put something into the database, I would
imagine, to make that flag more permanent.  I think it's an interesting


-----Original Message-----
From: Chris Conrad []
Sent: Tuesday, May 03, 2005 1:45 AM
Subject: Designing with Hivemind best practices

I'm hoping that maybe we can strike up a discussion on some design 
best practices when working with Hivemind.  Unfortunately, I'm not 
the one to do much talking, but I'd like to pose some questions that 
might get the ball rolling.

After reading through The Server Side article and the documentation 
it's my understanding that Hivemind services should small and fine 
grained.  Assuming that I've got that aspect correct, my question 
would be, what is too small?  For example, in the article there is a 
RegistrationService, UserFactory and UserRepository.  If I was to 
start a design from scratch the most logical design for me would be 
to combine the RegistrationService and UserFactory into a single 
UserService and then keep the UserRepository as is.  How do you guys 
decide when a service is fine grained enough, or in the alternative, 
what is too fine grained?

My second thought topic involves application installation.  I'm going 
to use a standard J2EE web application for examples sake.  From my 
experience, you'd first set up your container as necessary (database 
connections, javamail sessions, etc.) and then deploy your war or 
ear.  At that point, however, most applications still have a good 
amount of application specific that still needs to be done.  For 
example, setting up default preferences, creating the first admin 
user, etc.  In the past I've simply had all of that in the database 
sql initialization scripts.  It seems to me, however, that Hivemind 
presents some interesting opportunities to make this more user 
friendly.  For example, an InstallerService could have a contribution 
point which takes Installer services.  These can provide (if we were 
using Tapestry) a Tapestry component and label.  The InstallerService 
can use a Wizard component which pages through the different 
Installer component contributions.  The individual Installer 
components could use ApplicationDefaults for the default values.  
Then the Tapestry front end can check with the InstallerService to 
see if installation is complete.  If it isn't, it can redirect to the 
wizard which allows the user to do the initial configuration.

Hopefully this isn't too off topic for the list, but I'm really 
interested in what people think about these things.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message