Its good to see the tide turning against the flawed idea that you can have a domain model thats both behaviorally rich and yet never initiates interaction with the world around it.

Other than domain -> repository access, the other archetypal case of useful domain -> service access are services that listen to domain events. Eg you might want to send an email to Prod Support when a BankAccount becomes illegally overdrawn.

In my Spring/Hibernate-flavored enterprise world, support for injecting into domain objects is still a practical sticking point. My colleagues oppose the AOP-based weaving model provided by Spring 2.0 as too much “techno-magic”.

You say ‘The transaction script (e.g. struts action in a web application if you’re so inclined) is simply responsible for finding an appropriate entry-point into the domain, then telling that domain class to do some work.’

Are you aware of Naked Objects - we’ve taken this to the extreme, whereby you don’t have any (developer-written) controllers at all. The framework provides you with direct access to the domain objects and their public methods. I think you’d love it. And to get you to the domain objects, we simply provide the user with direct access to (a subset of methods on) the Repositories, which we use in exactly the same way that you do.

I’d be interested to hear your reactions to this idea.

Richard