Re: How-to implement the e-Commerce-System found in the "IDDD" book

Maybe you should save noncompleted ones since you allow association?

On Tuesday, June 4, 2013, Mauro Servienti wrote:

> **
>
>
> A document-db is a perfect suite for historical data, but in the end is
> just a tech detail.
>
> Creating "invoice B" that refers to a non-already saved "invoice A" to me
> sounds really like an over-engineering scenario, can it really happen? If
> it can the command "CreateAssociatedInvoice" must carry with itself all the
> details of the non-already saved invoice so that the next step does not
> need the read-model to move on.
>
> .m
>
> -----Original Message-----
> From: [email protected] <javascript:_e({}, 'cvml',
> 'domaindrivendesign%40yahoogroups.com');> [mailto:
> [email protected] <javascript:_e({}, 'cvml',
> 'domaindrivendesign%40yahoogroups.com');>] On Behalf Of j.vieten
> Sent: martedì 4 giugno 2013 11.09
> To: [email protected] <javascript:_e({}, 'cvml',
> 'domaindrivendesign%40yahoogroups.com');>
> Subject: [domaindrivendesign] Re: How-to implement the e-Commerce-System
> found in the "IDDD" book
>
> I was when I started this thread unsure if the process of creating
> 3 BCs was worth the extra work.
> But I am already getting some help here on how-to build the models so this
> must be good (-:
>
> Yes the invoicing needs to historicly store its data. I therefore could
> use a read database schema for this.
>
> Most of my invoice logic takes place when "creating" an invoice. The user
> kind of works in a excel sheet (ajax enriched form) where he can turn on
> and off lots of knobs. Since the created invoice may need to refer to past
> invoices I am not sure if the read database might even complicate
> things.(Also the ajax Interface by no means is a task oriented interface)
> Scenarios like create invoice A. publish Event "Invoice A created"
> create Invoice B that refers to Invoice A. But maybe Invoice A hasnt been
> yet saved to the read database. But on the other hand a read database
> architecture does also seem very helpfull for dealing with historical
> data.....
>
> --- In [email protected] <javascript:_e({}, 'cvml',
> 'domaindrivendesign%40yahoogroups.com');>, Greg Young <gregoryyoung1@...>
> wrote:
> >
> > There is no suc thing as fresh information.
> >
> > On Monday, June 3, 2013, Mauro Servienti wrote:
> >
> > > **
> > >
> > >
> > > But, if in your scenario makes sense to regenerate the order each
> > > time it is opened you can issue a query to the product BC, via a
> > > service exposed by the product BC using a dedicated read model for
> > > the order - product communication, in any case the order aggregate
> > > does not need the product aggregate for this task.
> > >
> > > The problem you have to face is: since you can totally isolate
> > > (different processes on different servers) BCs what happens when you
> > > query for an order and the product BC is not available?
> > >
> > > There are scenario in which makes sense that the order is available
> > > with stale information and other where you need all the time as much
> > > as possible fresh information and others where you _must_ have fresh
> information.
> > >
> > > .m
> > >
> > > -----Original Message-----
> > > From: [email protected] <javascript:_e({}, 'cvml',
> 'domaindrivendesign%40yahoogroups.com');> <javascript:_e({}, 'cvml',
> > > 'domaindrivendesign%40yahoogroups.com');> [mailto:
> > > [email protected] <javascript:_e({}, 'cvml',
> 'domaindrivendesign%40yahoogroups.com');> <javascript:_e({}, 'cvml',
> > > 'domaindrivendesign%40yahoogroups.com');>] On Behalf Of
> > > wonderfulworldofpingpong
> > > Sent: luned� 3 giugno 2013 22.43
> > > To: [email protected] <javascript:_e({}, 'cvml',
> 'domaindrivendesign%40yahoogroups.com');> <javascript:_e({}, 'cvml',
> > > 'domaindrivendesign%40yahoogroups.com');>
> > > Subject: [domaindrivendesign] Re: How-to implement the
> > > e-Commerce-System found in the "IDDD" book
> > >
> > > I don't agree to this. Regenerating an order requires a query to the
> > > BC that contains the Product.
> > >
> > > > - Independency: Order-BC should not depend on the availability of
> > > > the
> > > Product-BC to work;
> > >
> > > ------------------------------------
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> >
> >
> > --
> > Le doute n'est pas une condition agr�able, mais la certitude est
> absurde.
> >
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>  
>


-- 
Le doute n'est pas une condition agréable, mais la certitude est absurde.