Re: DOM and Database

yes your explanation does get me started.

I do plan to use a web REST Service. What is special about my use-case is that my
entities need to provide many calculations based on many aggregate members.
So I have for example a domain service method calcPredictionOfProject(options) which works its way through all the entities and their aggregates. Depending on the options provided certain aggregates might also do special calculations when contributing to calcPredictionOfProject.

It would not perform if I would need to rebuild all entities on every call to calcPredictionOfProject.

But now that you explained to me that a DDD Model can be statefull and kept in memory
I think I need to find ways to make my DDD Model nevertheless scaleable and still as simple as possible.
Many Greetings
John


--- In [email protected], Jörgen Andersson <jorgen.x.andersson@...> wrote:
>
> 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 <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?
> >
> >  
> >
>




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