Re: DOM and Database

On 5/14/13 14:13 , j.vieten wrote:
> Hello,
> I am very new to DDD...
> Many examples I have seen so far more or less reconstruct their Domain
> Object Model (DOM) on every service call. In the following "persistence"
> could be Hibernate or even just jdbc
> So the flow is
> 1) service call A
> 2) "persistence" goes to DB and constructs the needed DOM
> 3) DOM returns result to service A
> 4) service call B
> 5) "persistance" goes to DB and constructs again the needed DOM
> 6) DOM returns result to service B
> ...
> But I would much prefer the following:
> 1) At the beginning of my application I construct a DOM which can answer
> all server requests.
> 2) service call A
> 3) DOM returns result to service A
> 4)service call B
> 5) DOM returns result to service B
> ....
> Since in most of the examples I `ve seen the first approach seems to be
> mostly used....
> Is there something wrong with using
> the second approach together with a persistence framework? Or is it just
> not practical for a enterprise application?

This depends a lot on whether your app is clustered or not, i.e. if it 
is the same server that gets write requests. You can always add caching 
of the constructed DOM, and if you know you're the only write point 
(e.g. you are using master/slave setup), then it is easy. If you have 
multi write, then you might have to do at least a version check of your 
cached object before continuing. OR, you can assume that it is fine and 
do the write, and on commit when you get versioning errors you can 
reload and retry.

It. All. Depends.

/Rickard



------------------------------------