Event Sourcing - Aggregate modeling -

two questions 1) how model aggregate , reference between them 2) how organise/store events can retrieved efficiently

take typical use case example, have order , lineitem (they aggregate, order aggregate root), , product aggregate. lineitem needs know product, there 2 options 1) lineitem has direct reference product aggregate (which seems not best practice, violate idea of aggregate being consistence boundary because can update product aggregate directly order aggregate) 2) lineitem has productid.

it looks 2nd option way go...what think here?

however, problem arises building order read/view model. in order view model, needs know products in order (i.e. productid, type, etc.). typical use case reporting, , commandhandler can use product object perform logic such whether there many particular products, etc. in order it, given fact data in 2 separate aggregate, need 1+ database roundtrips. using events build model, pseudo code looks below 1) given order id (guid, order aggregate id), load events it; -- 1st database access 2) build order aggregate, know productid referenced in order; 3) list of productids, load events it; -- 2nd database access

if build big graph of objects (a lot of different aggregates), may end few more database access (each of slow)...what's idea in here?

thanks

take typical use case example, have order , lineitem (they aggregate, order aggregate root), , product aggregate.

the order aggregate makes sense way have described it. "product aggregate" more suspicious; ask model if product allowed change, or telling model product has changed?

if product can change without first consulting order, lineitem must not include product. reference product (aka productid) ok.

if build big graph of objects (a lot of different aggregates), may end few more database access (each of slow)...what's idea in here?

for reads, reports, , -- aren't going adding new events history -- 1 possible answer slow work in advance. asynchronous process listens writes in event store, , publishes events bus. subscribers build new versions of reports when new events observed, , cache results. (search keyword: cqrs)

when client asks report, give them 1 out of cache. work done, it's quick.

for command handlers, answer more complicated. business rules supposed in domain model, having command handler try validate command (as opposed domain model) bit broken.

the command handler can load products see state might like, , pass information aggregate command data, it's not clear that's idea -- if client going send command run, , need flesh out order command product data, why not instead have command add product data command directly, , skip middle man.

commandhandler can use product object perform logic such whether there many particular products, etc.

this example bit vague, taking guess: thinking cases prevent order being placed if available inventory insufficient fulfill order.

for real world inventory - physical book in warehouse - that's wrong approach take. first, model wrong; if want know how product in warehouse, should querying warehouse, not product. second, physical warehouse not constrained model -- calling addproduct method on warehouse aggregate doesn't cause product magically appear there.

third, doesn't match domain experts want anyway. if model says warehouse doesn't have enough product, think stake holders want system to

1. tell shopper buy product somewhere else, or...
2. accept order, , contact supplier new delivery.

hint: when in doubt, review how amazon.com it.