Thanks Erik, but the credit has to go to Ben Alex of Acegi for the implementation framework.Very nice architecture, Alan. I'm also reading Domain Driven Design, and your approach is along the lines of what I was considering for my project as well.
I've not found this a problem so far. Each domain object has a private no argument constructor to satisfy Hibernate and a constructor taking in the mandatory arguments. If these are immutable, then only getters are provided. If there are other attributes that are optional and mutable, then public setters are provided as well, which also check the content for null etc. Thus, for example, if my Employee object requires it's Cost Centre (which is another persistable entity in a different package) to be changed then the cost centre setter on Employee can be called from within the model or from the facade.One concern I have, however, is the package protection limiting the interaction between different rich domain objects. The natural solution to this is of course to put all domain objects that need to call each others' methods directly in the same package (as in DDD figure 7.8). This could, however, result in very large, and at least in my mind, cluttered packages if you have to include all the infrastructure classes as in your employee example. Is this just something that I need to "get over" or are there any neat solutions that you have thought of?
My facades still only deal with accepting and returning DTOs to and from the web client. It is already possible to use Acegi Secuirty (via AOP) to limit access to methods. I'll be looking into this as a possibility to tighten up the security.
Also, when designing a new DO, declare each attribute with a javadoc comment above to say whether it's mandatory or optional, mutable or immutable. It helps a lot to then determine what constructors and what getters and setters to provide. It ensures that each DO will always be in a consistent correct state.