Java/JSF/Spring/WebFlow DDD architecture design question

I'm currently porting a massive, ancient, Oracle Forms app over to JSF & I need to make decisions on the domain model.

I'm locked in to using the Spring JDBC templates(no ORM) and utilizing a DAO layer to deal with baffling legacy database schema, which must have been desined by 1st year co-ops. For the domain model I would really like to make things highly OO, for instance: presume there is a domain object Plan. The goal would be too OO-ify it be able to do PlanInstance.load(byId("12345")), PlanInstance.save(), .delete(), .create(), etc etc. But then the situation arises; because these domain objects contain references to stateful beans(like Repositories for instance), then they can't be Serialized. How does one overcome this?

Initially I started splitting things up like: PlanData(Statefull, SessionScoped) which is used by PlanManager(Stateless, Singleton). This way the common contro开发者_开发百科ller code is extracted and is prevented from being duplicated in each session scoped bean, and most importantly allows the session scoped beans to be serialized.

At this point I really need to structure it OO style to minimize complexity, but I just don't know how I can have an object in session scope when it has references to stateful objects(due to serialization errors).

The only possibility I can think of is makeing the stateful refs transient & devising some sort of mechanism to re-inject the dependancies when a bean is un-serialized. Can any one provide me with any insight into solutions to this dilemma? There must be some sort of pattern/practice that solves which I am probably just missing.

I would keep the state and management of that state separate (i.e. Plan vs PlanManager.) By using the data access pattern (PlanManager), you keep the door open to using ORM later, (say) should the db schema be reworked in future. Putting state and state management together in the same class (PlanInstance) goes against the OO principle of single responsibility.

The stateful session scoped beans are not themselves serialized (at least not to store in your persistent store - but you might serialize them to support session fail over). The controller and session beans maintain references to your data beans.

The stateful beans decide when to load, invoking logic, change state and save your data objects. They provide the context for your domain objects. In some designs (often cited as the Anemic Domain Model) the domain objects have no behaviour, and all the logic exists in stateless services. If I understand correctly, you want encapsulation of state and behaviour in your domain objects, and that the domain objects need to use stateful session beans to perform their work. Where possible, try to factor the functionality in the domain objects to not rely upon session state (will make testing simpler), or to push that functionality out into a service bean that is invoked with the appropriate session state. If you have no choice but to use references to stateful beans from your domain model behaviour, the stateful beans can provide the necessary state/repository references as parameters to method calls on your domain objects. That way, the domain objects are still stateless, but can implement domain logic using stateful beans.

All the while, consider the single responsibility of the domain object. At some point it may become clear that the domain logic can be split into layers (say, low-level and higher-level logic) which may make the need for stateful beans in the domain objects unnecessary.