approach to domain/aggregate management.

[erich]

Just wanted to confirm something.  In the example application the InvoiceService uses that invoicesRef to manage the map of invoices.  But in a 'real world' implementation, I guess that should be replaced with a repository to persistent storage?

[Martin Krasser]

No, persisting current state is exactly what you want to avoid with
event sourcing. With event sourcing, you persist changes and recover
current state by replaying these changes, hence you can keep current
state in memory.

> --
> You received this message because you are subscribed to the Google
> Groups "Eventsourced User List" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to eventsourced...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

--
Martin Krasser

blog: http://krasserm.blogspot.com
code: http://github.com/krasserm
twitter: http://twitter.com/mrt1nz

[erich oliphant]

Yeah, I meant to update the email.  Kind of had a 'duh' moment :)  Though a quick question.  In looking at the InvoiceService implementation it, as you said keeps the invoicesRef as an in memory store based on the events that have been handled.  Does this approach break down at some point?  If I've say hundreds of thousands of invoices?

On Mon, Nov 11, 2013 at 11:56 PM, Martin Krasser <kras...@googlemail.com> wrote:

On 11.11.13 21:26, erich wrote:

Just wanted to confirm something.  In the example application the InvoiceService uses that invoicesRef to manage the map of invoices.  But in a 'real world' implementation, I guess that should be replaced with a repository to persistent storage?

No, persisting current state is exactly what you want to avoid with event sourcing. With event sourcing, you persist changes and recover current state by replaying these changes, hence you can keep current state in memory.

--
You received this message because you are subscribed to the Google Groups "Eventsourced User List" group.

To unsubscribe from this group and stop receiving emails from it, send an email to eventsourced+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
Martin Krasser

blog:    http://krasserm.blogspot.com
code:    http://github.com/krasserm
twitter: http://twitter.com/mrt1nz

--
You received this message because you are subscribed to the Google Groups "Eventsourced User List" group.

To unsubscribe from this group and stop receiving emails from it, send an email to eventsourced+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
Erich Oliphant

"There are, in fact, two things, science and opinion, the former begets knowledge, the latter ignorance"
-- Hippocrates of Cos

[Martin Krasser]

On 12.11.13 06:06, erich oliphant wrote:

Yeah, I meant to update the email.  Kind of had a 'duh' moment :)  Though a quick question.  In looking at the InvoiceService implementation it, as you said keeps the invoicesRef as an in memory store based on the events that have been handled.  Does this approach break down at some point? 

What do you mean by "break down"?

If I've say hundreds of thousands of invoices?

On Mon, Nov 11, 2013 at 11:56 PM, Martin Krasser <kras...@googlemail.com> wrote:

On 11.11.13 21:26, erich wrote:

Just wanted to confirm something.  In the example application the InvoiceService uses that invoicesRef to manage the map of invoices.  But in a 'real world' implementation, I guess that should be replaced with a repository to persistent storage?

No, persisting current state is exactly what you want to avoid with event sourcing. With event sourcing, you persist changes and recover current state by replaying these changes, hence you can keep current state in memory.

--
You received this message because you are subscribed to the Google Groups "Eventsourced User List" group.

To unsubscribe from this group and stop receiving emails from it, send an email to eventsourced...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
Martin Krasser

blog:    http://krasserm.blogspot.com
code:    http://github.com/krasserm
twitter: http://twitter.com/mrt1nz

--
You received this message because you are subscribed to the Google Groups "Eventsourced User List" group.

To unsubscribe from this group and stop receiving emails from it, send an email to eventsourced...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
Erich Oliphant

"There are, in fact, two things, science and opinion, the former begets knowledge, the latter ignorance"
-- Hippocrates of Cos

--
You received this message because you are subscribed to the Google Groups "Eventsourced User List" group.

To unsubscribe from this group and stop receiving emails from it, send an email to eventsourced...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[erich oliphant]

Sorry :)  I meant how would such an approach behave at large scales.  If there's hundreds of thousands or say millions of invoices in the example case, would there be a need to move some other representation.  Like say an external cache that can 'overflow' to disk as needed etc.

[Martin Krasser]

On 12.11.13 15:49, erich oliphant wrote:

Sorry :)  I meant how would such an approach behave at large scales.  If there's hundreds of thousands or say millions of invoices in the example case, would there be a need to move some other representation.  Like say an external cache that can 'overflow' to disk as needed etc.

Eventsourced doesn't make any assumptions how applications manage state, so you can add domain objects to any distributed storage solution you want. Alternatively, you can also partition/shard invoices by having n InvoiceProcessors on different nodes, each maintaining its own partition. Anyway, there's no built-in support in eventsourced for doing that.

[erich oliphant]

Gotcha, makes sense.  Thanks!