Architecture: Gestion de l'historique des commandes

Question

Je travaille sur un nouveau modèle de domaine pour une application qui traitera des commandes pour les éléments intégrés (bien, gardez-le de toute façon pour cette question). J'ai une classe "VendorItem" qui représente les éléments qui peuvent être commandés. A l'origine, la classe "Order" allait avoir une liste de VendorItems associée, mais j'ai rencontré des problèmes avec elle jusqu'à présent.

Supposons que le système crée des commandes depuis un bon moment. Un jour, un utilisateur arrive et décide qu'un fournisseur a changé de prix ou d'autres détails comme la taille de l'emballage. Je ne voudrais pas que les commandes précédentes soient affectées par un tel changement. Au premier lavage j'allais faire une classe "OrderLine" qui est fondamentalement une copie de la classe "VendorItem", mais cela sent juste (sent mauvais?) Au sens OO.

Existe-t-il une meilleure façon de refactoriser cela afin que je n'ai pas de copies de classes et d'informations dans le modèle de domaine?

Answer 1

Oui, vous pouvez utiliser des "passe-partout", ok de toute façon l'idée est que vous avez un objet qui représente le "produit" de votre article, des patins ou autre, alors vous avez cet objet composé de quelque chose, Pour chaque commande, vous devez assigner un objet de prix. Ainsi, lorsque vous modifiez un prix ou quelque chose de ce genre, vous affectez simplement un nouvel objet prix (avec des args différents) à vos objets Item. de vos articles et vous avez un objet de prix qui définit le prix et les caractéristiques de cet article (pour représenter les attributs qui pourraient changer au fil du temps). Dans ce cas, l'élément standard est l'élément car il ressemble à un modèle et ne change jamais, et vous personnalisez avec votre objet Price (dans les exemples donnés)

Answer 2

Dans le passé, j'ai créé des classes "Variation". Un VendorItem contient des "Variations" Une variation peut être une taille de t-shirt, ou une saveur de sous-vêtements. Chaque variation porte son propre prix, de sorte que vous pouvez faire des culottes de chocolat plus chères que celles de fraises. La classe OrderLine a une référence à l'ordre, à la variation, à la quantité et au prix. Vous gardez le prix dans OrderLine afin que vous puissiez changer le prix de la variation plus tard sans affecter les procédures d'audit. Ensuite, au lieu de modifier un élément existant, vous pouvez simplement ajouter une variante et définir l'ancienne comme "InActive"

Ai-je trop parlé de l'entreprise familiale?

Answer 3

IMO vous devriez cela principalement géré par votre base de données. Que chaque produit que vous appelez un VendorItem a un PK avec un début effectif (null non autorisé) et une date de fin effective (éventuellement nul pour gérer le courant jusqu'à son arrêt) avec toutes les informations relatives à l'article.

Dans votre table de commande, vous devez avoir un CustomerID associé à 0 à plusieurs ID de commande avec l'enregistrement contenant une clé étrangère à VendorItem qui a été vendue à ce moment-là. De cette façon, vous pouvez suivre toutes les modifications qui ont déjà été apportées à vos lignes de produits, et permettre une analyse facile des changements de prix, des changements de description, etc., et des effets sur les ventes facilement.

À l'intérieur de votre code, presque rien ne changerait, sauf pendant le processus de commande/affichage processus que vous obtenez l'élément actuel de la table des produits.

Answer 4

Je trouve beaucoup plus facile de décrire d'abord tout ce que vous savez sur les objets tels qu'ils existent réellement, et non comme des classes. Ensuite, déterminez la hiérarchie des informations, puis comment modéliser cela avec les classes.

Par exemple: Un article est un produit que vous achetez auprès d'un ou de plusieurs fournisseurs, généralement défini par un code UPC (Universal Product Code - le code à barres enregistré).

Le fournisseur a souvent également un numéro d'identification interne, communément appelé numéro d'article du fournisseur (VIN).

Un élément peut venir dans différentes tailles et couleurs, tous avec le même UPC - mais différents VINs éventuellement avec des coûts différents:

T-Shirt UPC 9055540022 
VIN: 40001 - Large, White - $5.00 
VIN: 40002 - Small, White - $4.00 
VIN: 40003 - Large, Green - $5.00 
etc. 

et les coûts sur ces éléments/VINs changeront au fil du temps. Une commande est une liste d'articles et leur coût à un moment donné, de sorte que vos informations de commande devront inclure le coût et toute autre information variable sur les articles de la commande.

Donc, si l'élément UPC est au sommet de la hiérarchie de l'information:

Item - 1 record per item - Descriptive info, UPC 

Vendor - 1 record per vendor - Vendor info 

VendorItemVin - 1 record per Vendor/Item/VIN - Vendor specific info, size/color/cost etc. 

Ensuite, vous pouvez avoir une idée de ce que les tables de base de données devrait ressembler, puis de travailler les classes.