Practical DDD: to inject into domain objects, or not to inject?

Hi,

I'm investigating the merits of the DDD approach, by applying it to a pet project. I want to find the "proper" way of using it, before I start messing with real projects. I've been working on this for a couple of weeks and have some thoughts I'd like to share. If you'd like, please read on and comment, especially if you've used DDD in "real life" projects. I appreciate any insight on this.

1) DDD is about modeling your business domain. It doesn't offer much as far as the service or presentation layer is concerned. Any effects are the result of not having an anemic domain, which means you can bundle more business logic into the business domain (where it naturally belongs). Other than that, the rest of your application is pretty much the same.

2) I see a lot of examples around that inject "repositories" into business objects and access persistence from that layer. I've been trying to do things that way, but I don't see much value in that. Main reason is that I like to use a clear "transaction demarcation" boundary. So my services tier usually has @Transactional methods that are used to start a transaction and all code that touches the DB must go through those. Once you start writing methods like "SomeService.saveSomeBusinessObject()" in the services tier, there's not much point in having a "SomeBusinessObject.save()" in the object itself. You can simply do that by injecting a DAO to the services tier (i.e. SomeService) and persisting the object from there.

What's your take on the above?