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

Exactly, something like a draft-invoice.

.m

From: [email protected] [mailto:[email protected]] On Behalf Of Greg Young
Sent: martedì 4 giugno 2013 17.21
To: [email protected]
Subject: Re: [domaindrivendesign] 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(%7b%7d,%20'cvml',%20'domaindrivendesign%40yahoogroups.com');> [mailto:[email protected]<javascript:_e(%7b%7d,%20'cvml',%20'domaindrivendesign%40yahoogroups.com');>] On Behalf Of j.vieten
Sent: martedì 4 giugno 2013 11.09
To: [email protected]<javascript:_e(%7b%7d,%20'cvml',%20'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(%7b%7d,%20'cvml',%20'domaindrivendesign%40yahoogroups.com');>, Greg Young <gregoryyoung1@...<mailto: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(%7b%7d,%20'cvml',%20'domaindrivendesign%40yahoogroups.com');> <javascript:_e({}, 'cvml',
> > 'domaindrivendesign%40yahoogroups.com<http://40yahoogroups.com>');> [mailto:
> > [email protected]<javascript:_e(%7b%7d,%20'cvml',%20'domaindrivendesign%40yahoogroups.com');> <javascript:_e({}, 'cvml',
> > 'domaindrivendesign%40yahoogroups.com<http://40yahoogroups.com>');>] On Behalf Of
> > wonderfulworldofpingpong
> > Sent: luned� 3 giugno 2013 22.43
> > To: [email protected]<javascript:_e(%7b%7d,%20'cvml',%20'domaindrivendesign%40yahoogroups.com');> <javascript:_e({}, 'cvml',
> > 'domaindrivendesign%40yahoogroups.com<http://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.