How to design an e-commerce website Step by step with DDD (vi)-add material to the shopping cart and integrate the selling price context

Read Catalogue

• Objective
• How to implement multiple contexts of business in a project
• The integration of the selling price context with the purchase context
• Conclusion

First, preface

The first few have implemented the simplest buying process, and this time it's starting to add something to the process. For example, promotions, membership prices, etc., in our first article (how to design an e-commerce website (a)--first understand the core concept) in the context map of the plan, which belongs to a separate context (the price context).

Ii. How to implement multiple contexts of business in a project

In general, in order to better divide and conquer, the different contexts as separate service, and then through the RPC framework (such as WCF) to access it is a more common practice. But in some small teams, although different contexts are divided, our development team is the same. In this case, it is my personal practice to set up different projects directly in the same solution, but there is a need to clearly divide the boundaries between the different contexts in the solution, and manage the boundaries without being destroyed by means of code reviews.

　　

"Figure 1"

Add a few items as shown in 1.

 

third, the price context and the integration of the purchase context

according to our first article How to design an e-commerce website with DDD One step at a--first understand the context map defined by the core concept and the 9 integration patterns can be seen, these 2 contexts in the same sub-domain, and in our actual business scenario, these 2 are complementary to each other, So the price context and purchase context are a partnership. After establishing this relationship, what is the appropriate context for the calculation logic of this promotion? Let's start with a few possible ways:

1. The purchase context drops the item information in the cart to the price context--The price context--and returns the result back to the purchase context.

2. The purchase context obtains the relevant member price and promotion information from the sales price context-and then the local shopping cart object based on the calculation, and directly can apply the results.

3. Pull out a dedicated computing service (which is part of the selling price context) to do the calculation. The purchase context drops the item information in the shopping cart to the calculation service--The calculation context gets the relevant member price and promotion information from the pin price context, and the results are returned to the purchase context

I believe 1 and 2 are the more mainstream of the 2 ways. But mode 2 is the price context only as a provider of data, which makes the partnership into a upstream and downstream relationship, and this way make the promotion rules and shopping cart strong coupling together, not conducive to the change of promotion rules. Here the price context only plays a simple role of data maintenance, unable to fully control the definition of "price", does not do a good job separation. Way 1 and 3 for the purchase context is actually no difference, just way 3 let the entire data interaction link a layer more, will incur additional overhead, the benefit is finer granularity of service, need to combine the actual situation to weigh the gains and losses. Here I choose 1 ways to achieve this, because we are at the beginning of the project, or as far as possible to reduce the non-business purposes of the split caused by the additional costs.

OK, after determining the integration method, first set the DTO model for data interaction between the 2 contexts, such as 2 (the DTO model for the price context), and Figure 3 (the value object corresponding to the former in the purchase context).

"Figure 2"

"Figure 3"

In addition, a isellingpriceservice is added to Figure 3, which abstracts the interaction with the selling price context. Then we add an anti-corrosion layer to this context in the Mall.Infrastructure.Translators project, the old 3-sample Sellingpriceadapter (the adapter that initiated the context data request), Sellingpriceservice (implement Isellingpriceservice), Sellingpricetranslator (to convert remote data objects to the cost of the value of the object), the code is very simple you can see in the source. It is important to note that The Mall.Infrastructure.Translators project here only adds a reference to the Mall.Application.SellingPrice project, similar to treating it as a remote resource (as stated above, if the actual responsibility of the different teams can be physically separated to 2 Solutions).

Finally create a cartservice, the inside of the Getcart () method--to get the shopping cart information, as the initiator of the call. This implementation uses the simplest way, not to do any data redundancy locally, the code is as follows:

     Public classCartservice {Private ReadOnly StaticConfirmusercartexisteddomainservice _confirmusercartexisteddomainservice =NewConfirmusercartexisteddomainservice ();  PublicCartdto Getcart (stringuserId) {            varCart =_confirmusercartexisteddomainservice.getusercart (userId); if(cart.) IsEmpty ()) {return NULL; }            varSellingpricecart =Domainregistry.sellingpriceservice ().            Calculate (CART); returnConverttocart (cart, sellingpricecart); }        Privatecartdto converttocart (cart cart, Sellingpricecart sellingpricecart) {return Newcartdto {cartitemgroups= SellingPriceCart.CalculatedFullGroups.Select (ent =Newcartitemgroupdto {cartitems= ent. Calculatedcartitems.select (E =Converttocartitem (E, cart. Getcartitem (E.productid)). ToArray (), Reduceprice=Ent. Reduceprice}). ToArray (), Cartitems= SellingPriceCart.CalculatedCartItems.Select (ent =converttocartitem (ent, cart. Getcartitem (ent. PRODUCTID)).        ToArray ()}; }        Privatecartitemdto Converttocartitem (Sellingpricecartitem sellingpricecartitem, Cartitem CartItem) {varProduct =Domainregistry.productservice ().            GetProduct (Cartitem.productid); return Newcartitemdto {ProductId=Cartitem.productid, ProductName= Product = =NULL?"product has expired": Product. Salename, Reduceprice=Sellingpricecartitem.reduceprice, Saleprice=Cartitem.price}; }    }    

Iv. Conclusion

There's a global change. Here, I've changed all the previous GUID identifiers to string types in this code, weakening data type constraints on unique identities, increasing extensibility (such as self-increment fields, other custom unique identities, etc.). In addition, the price in the shopping item is changed to UnitPrice, which makes the semantics clearer. The content of this article is quite coarse, welcome everybody to discuss.

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

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

How to design an e-commerce website Step by step with DDD (vi)-add material to the shopping cart and integrate the selling price context