Reduce the amount of locations where user-information (eg. Address, Name) are stored.

[bummzack]

Fields like FirstName, Surname etc. are currently stored in Address, Order and Member, which can to differently populated data (eg. the Address might lack FirstName and Surname, while the data resides in Member).

The following change could improve the situation:

• No longer store any Address related fields within Order
• The main authority about which fields form an Address should be Address (one single point of extension)
• Member addresses can lack the properties that are already present in the Member object
• Upon placing an order, create new Address instances which are unique to the order. These instances should contain complete information (merge data from Member and Address). This will also prevent address modifications by the user once an order is placed.

[bummzack]

I think the main issue here is to determine what Address instance will contain the customer information? The natural reaction would be to use the Shipping-Address, however if somebody specifies a shipping-address for a gift and uses a separate billing-address, then the customer would be stored in the billing-address.

I don't think there's a good/easy solution to this, so leaving it as is, is probably best: The customer is stored in Member or Order (jn case of guest checkout). The addresses are stored in Address DataObjects…

What can be done as an improvement would be to ensure the Customer fields get shown in the CMS and Order as well (as of now, a Guest order will not show Firstname and Surname in the CMS orders!).

Any objections? @markguinn, @wilr, @anselmdk ?

[bummzack]

Some improvements have been made via #518 I think we could even leave it at that for 2.0