How to design an e-commerce website Step by step with DDD (10)--a complete shopping cart

Read Catalogue

• Objective
• Review
• Comb
• Realize
• Conclusion

First, preface

　　The previous article has involved the purchase of items added to the shopping cart, shopping cart in the amount of items such as the calculation functions. This article prepares to finish the basic concept of the remaining shopping cart at once.

Second, review

　　Before I started, I made a review of the objects in the previous purchase context. Let's start by combing through the domain objects that already appear within the context, as shown in 1:

　　　　　　　　　　　　　　　　　　　　　　　　　　"Figure 1"

During the grooming process, I reconstructed the original Cart.addcartitem (string productId, int quantity, decimal price) to Cart.addcartitem (product product, int Quantity), the benefits of this are 2:

1. The meaning of adding a product in a shopping cart is clearly stated.

2. Constrain the addition of the Product object to the external only through the products objects, so that the constraints in the product constructor do not have to be re-validated here (such as salename cannot be empty, etc.).

third, carding

There is only one method of operation in the current shopping cart. Referring to the current design of the mainstream e-commerce platform, we need to add:

1. Number of modifications

2. Delete

3. Select the participating promotion (if there are multiple non-single-grade promotions)

4. Collection Items

The first 3 is relatively simple, are the concept of the shopping cart itself, only the 4th is beyond the scope of the shopping cart itself, and I think the collection is not the concept of shopping cart-specific, but in any place to see the product can be added to the collection of operations. Then it naturally leads to a new concept-the collection folder. Take a look at the latest UML diagram, as shown in 2:

　　　　　　　　　　　　　　　　　　　　　　　　　　"Figure 2"

I think there will be a part of the students in the design of the collection (Favorites) will be done in another way, such as 3 like this:

　　　　　　　　　　　　　　　　　　　　　　　　　　"Figure 3"

Here I think the reason for this may be due to Dbfirst thought, because the "favorites" in Figure 2 simply maintains a relationship between "user" and "favorite", so long as you add a userid to the "Favorites", you can simply omit this layer of relationships. And the data structure is much simpler. At this time we need to pay attention to, must not have dbfirst thought to affect the domain modelling, such way will "add Shopping item" This kind of business meaning leaked to the repository layer or application layer to implement, resulting in the general language can not be a complete business description.

And in this scenario, my personal view is that the collection of goods is only for the display of the product to add a way, so it should be designed to exist independently, by itself to manage the "collection of goods", its existence or not affect other domain objects.

Iv. Realization of

　　To achieve these 4 operations, you need to add the following 4 interfaces to the Icartservice:

        Result changequantity (stringstringint  quantity);        Result Deletecartitem (stringstring  ID);        Result addtofavorites (stringstring  productId);        Result changemultiproductspromotion (string string Selectedmultiproductspromotionid);

　　Some of these implementations are as follows:

         PublicResult AddToFavorites (stringUseridstringproductId) {            varCart =_confirmusercartexisteddomainservice.getusercart (userId); if(cart.) IsEmpty ()) {returnResult.fail ("There are no items in the current shopping cart"); }            varCartitem =cart.            Getcartitem (PRODUCTID); if(Cartitem = =NULL)            {                returnResult.fail ("the shopping item no longer exists"); }            varFavorites = Domainregistry.favoritesrepository (). Getbyuserid (userId)??NewFavorites (UserId,NULL); Favorites.            Addfavoritesitem (Cartitem); Domainregistry.favoritesrepository ().            Save (Favorites); returnresult.success (); }

　　One of the constructors for favorites is this:

         PublicFavorites (stringUserId, ienumerable<favoritesitem>Favoritesitems) {            if(string. Isnullorwhitespace (userId))Throw NewArgumentNullException ("userId");  This. UserId =userId;  This. _favoritesitems =NewList<favoritesitem>(); if(Favoritesitems! =NULL&&Favoritesitems.any ()) {                foreach(varFavoritesiteminchFavoritesitems)                {Addfavoritesitem (Favoritesitem); }            }        }

　　This allows you to reuse some of the guard operations in the Addfavoritesitem to ensure that the data is in the process of being validated when the historical data is removed from the DB after the business has been changed. This method can be timing used in any of the aggregation constructors.

v. Conclusion

　　The main point of this thesis is to think about the inertia of modeling, throw out the db, throw out the db, throw out the db, the important thing to say 3 times.

The source address of this article: Https://github.com/ZacharyFan/DDDDemo/tree/Demo10.

Zachary_fan
Source: http://www.cnblogs.com/Zachary-Fan/p/DDD_10.html

How to design an e-commerce website Step by step with DDD (10)--a complete shopping cart