Re: How do you handle free-text associations with DDD

I think it is better to get a deeper understanding of domain.

Once published (finalized) an invoice becomes immutable. It's simply a historical record then. That means that any information which is the part of an invoice cannot  be changed. 

So if customer information (say an address) changes afterwards and you're only storing live reference to a customer entity (by means of customer id) on an invoice, next time you open it, instead of showing customer information that was actual at the moment it was published, it will show an updated customer information. Which is wrong and illegal amost everywhere.

Armed with this knowledge the solution is obvious - you need to copy all information referenced by invoice into invoice aggregate itself. Capture it. 

Then when you select customer from the list of existing customers (in GUI) you will just copy all of the relevant properties. Same with the free-form input - user can just fill out all of the relevant properties in-place, without bothering creating permanent customer data. This is especially useful, because usually there is no point to create permanent customer entity for one-time sales. But it depends on you business requirements.

So that means that you customer list is nothing more than a glorious autocomplete, which just prefills fields on an invoice with permanently stored customer information.

BTW, exactly the same situation is with invoice items.

Yevhen.

P.S. If you don't copy referenced information you will end up with silly things like multiversioning of referenced entities and all that jazz.


13 марта 2013, в 11:35, Giacomo Tesio <[email protected]> написал(а):

> 
> 
> What do you think about a hierarchy of Invoice (the abstract one, derived by the others), CustomerInvoice and FreeInvoice?
> CustomerInvoice would derive Invoice and use a CustomerIdentifier to relate to the customer and the FreeInvoice would simple use a string.
> 
> 
> Giacomo
> 
> On Tue, Mar 12, 2013 at 11:16 AM, codewithcoffee <[email protected]> wrote:
>>  
>> 
>> Hello All,
>> 
>> I will first present a simple example which I know that I shouldn't talk
>> about UI first, but it places the example in a context.
>> 
>> So - imagine two agg. roots: Invoice and Customer. Invoice has an
>> association to Customer, but there is also a possibility to define a
>> customer for an invoice by simply typing the customer name into the
>> "Customer" textbox. I would call this free-text.
>> 
>> There are two possibilities here as I see them:
>> 
>> - have a text property on Invoice in which the customer name is stored
>> (I would not go for this at all), and then provide messy code that
>> decides what to return when you ask for the Customer.
>> - create a new Customer when saving the Invoice, by providing his newly
>> typed name since this is the only dependency of the Customer root.
>> 
>> I would always lean for second approach, but take into account that we
>> don't want these "free" customers displayed in our "Customers view" for
>> example. So, what could you do? Add a property on Customer that would
>> distinguish these entries?
>> 
>> I would also presume that since this "feature" is required in the
>> domain, we would have requirements like: "User is able to define a Free
>> Customer on an Invoice" and an UI requirement like "User should not see
>> Free Customers in Customers View".
>> 
>> One option that I see is having inheritence in place here, meaning
>> specific entities Customer and FreeCustomer entities, but again I am
>> little confused how to model this in DDD way.
>> Would FreeCustomer inherit Customer which is agg. root? Would callers of
>> interating over all Customers try to cast to FreeCustomer? I generally
>> don't like inheritance that much.
>> 
>> This example is completely made up, and I know what there are no
>> "concrete" questions here; but I would appreciate any comments about the
>> thoughts given here :=)
>> 
>> Best regards, Denis
>> 
> 
> 
> 
>