Re: DOM and Database

Hi,

From a DDD-point-of-view both approaches will work. In both cases you build
a domain model to contain the business state and logic.
The difference is in whether the the application services are state-full or
stateless. Which one you choose has to to with what infrastructure is used
to deliver the application.
Since most enterprise systems tends to be web based in some flavor (web
apps or REST based) and you don't want to have the whole state for each
client stored on the server for scalability reasons the state-less approach
is more common. If you were to build a system where the domain model
executes on the client, e.g. a desktop or mobile app with less frequent
server round-trips, you would probably go with state-full application
services on the client to make things simpler and more efficient.

Hope this not so extensive explanation helps to give you some perspective
on your thinking on DDD-architectures.
/Jörgen


On 14 May 2013 08:13, j.vieten <[email protected]> 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?
>
>  
>