I'm about to rebuild an e commerce website with a mid sized database of about 40,000 product.
One of the main reasons we are putting the old system to retire is the categorization mechanism.
We are looking for something that will allow us to place an item under multiple categories, or even better having no fixed category at all and we can classify products by putting descriptive labels on them and the front user can search for the products by using these labels. (I don't even sure that this can be done from a programming point of view).
It will be helpful to know what this model is called, whether it was implemented before? and even better if you can refer me to ready solutions.
Related
What is the DDD way of handling the following scenario:
user enters Order Create screen and starts creatingnew Order with OrderItems
user chooses ProductX from products catalog and adds quantity
OrderItem for ProductX is created on Order and user goes on adding another product
in the meantime, before Order is saved, admin changes price for ProductX
Assuming Product and Order/OrderItem are separate aggregates, potentially even separate bounded contexts, how is this handled?
I can think of several options:
optimistic concurrency combined with db transactions, but then if we broaden the question to microservices where each microservice has its own db - what then?
joining everything into one giant AR but that doesn’t seem right.
introduce a business rule that no product prices are updated during the point of sales working hours but that is often not possible (time triggered discounts, e.g.)
What is the proper DDD/microservices way of solving this?
What is the proper DDD/microservices way of solving this?
The general answer is that you make time an explicit part of your pricing model. Price changes made to the product catalog have an effective date, which means that you can, by modeling time in the order, have complete agreement on what price the shopper saw at the time of the order.
This might introduce the concept of a QuotedPrice as something separate from the Catalog price, where the quote is a promise to hold a price for some amount of time.
To address this sort of problem in general, here are three important papers to review:
Memories, Guesses, and Apologies -- Pat Helland, 2007
Data on the Outside vs Data on the Inside -- Pat Helland, 2005
Race Conditions Don't Exist -- Udi Dahan, 2010
I think one way to solve this through is Events. As you said, Product and Order can are very least separate aggregates, I would keep them loosely coupled. Putting them into one single aggregate root would against Open/Close and Single Responsibility Principle.
If a Product changes it can raise a ProductChanged event and likewise of an Order.
Depending on whether these Domain-Objects are within the same service or different service you can create a Domain-Event or an Integration event. Read more about it here.
From the above link:
A domain event is, something that happened in the domain that you want other parts of the same domain (in-process) to be aware of. The notified parts usually react somehow to the events.
I think this fits perfectly to your scenario.
We are about to begin working on an addition to Magento 1.14.2 EE that will allow us to merchandise and sort products within categories at a store level. currently we do this by having 3 entirely separate root category trees, our editors are finding this cumbersome, and our indexing takes 3x the time it should take to reindex a single tree.
The plan is to add a store_id column to the catalog_category_product table which currently stores the product_id, category_id and products position within the category in question.
So my questions are fairly general at this point, has anyone attempted this previously and are there any obvious pitfalls that we are likely to encounter as a result of attempting this? The solution to us seems fairly obvious yet it hasn't been implemented yet by Magento, surely this is a piece of functionality that would be useful for any company that has a presence in multiple countries.
I have an e-commerce site that provides made-to-order clothing. I've created a configurable product and just one associated product.
Is it possible to display all of the possible attribute combinations within just one associated product rather than manually add every combination?
I've tried allowing out of stock products to be displayed, but this didn't show all of the possible combinations.
I'm not hugely experienced with Magento, but I've used many CMS systems and inventory management products. I've never once seen a matrix / configurable / multi-variation / whatever you want to call it setup where you didn't have to create each combination as a distinct SKU. I'm not saying it's 100% impossible, but I'd view it as extremely unlikely and probably a waste of time to pursue.
Why not just create your configurable products and their sub SKUs via CSV import? It will be far easier and faster than creating them one at a time. Creating every combination will also be extremely easy. If you're not comfortable with Excel, you need to correct that yesterday if you want to be good at product management.
See this article:
https://www.siteground.com/tutorials/magento/import-products.htm
really could do with your expert advice / knowledge & help...
We have a client who we built a magento site for. He sells parts for motorbikes, jet-skis, motocross etc..
We set up three attributes "Manufacturer" then "Model" then "Year" - and this was the selection process inside each product to drill down a price (as price changes on the models year) to achieve the pricing structure he wanted we used a simpler config products plugin that worked a charm. (which I found searching through these forums)
Problem.. The "Model" attribute is getting way too big (crashing the browser and timing out - and approaching what I have been told is the limit for attributes) so we have to rethink the logic (as last resort is to change the whole site and add them all as simple products and use filters instead - which the client does not want)
After days fo stress and researching we are still none the wiser...
one idea would be to split the model attribute into manufacturer.. so "Hond_Model" .. "Aprilla_Model" and so on.. but then we cant keep the structure of one product with all the options inside, be great of we could have inside the product (front end)
select honda model
select aprilla model
select Can Am Model
Year
but the user can choose one model from any three of the "model" drop downs, then it blanks out the other 2 model attributes and lets the user select the year to get a price.
But in the back end when I try this all three "Model" attributes have a red asterix and require an input in all three..
HELP!
Sorry if some of this is basic I am a designer who is learning magento with the help of my developer for the past 6 months so still new to this but already way out of my depth.
Any help would be so appreciated.
Given the level of complexity, the relative newness of your company with Magento, and particulars of the automotive fitment domain, it might be wise to buy an existing fitment module (e.g. Year Make Model Extension - not an endorsement - i have no firsthand knowledge of this extension) to bootstrap your development or to learn from. You should check with module vendor first to make sure that the code is suitable for this purpose (not obfuscated / encrypted, written using Magento conventions).
There are several approaches which can be taken depending on how frontend presentation and backend reporting should work, but these are too broad to be discussed here.
I've started working on a new Magento webshop which has roughly 250000 different products. Each product can have different conditions (new, used, damaged, etc., each with their own price.). Magento doesn't seem to have a method to implement this at the moment. Of those 250000 products, there are about 150000 different conditions in stock and another 150000 conditions which aren't in stock but do have a price (which can be put on the wishlist).
Some numbers: 1500 categories, drop down attributes (country) with > 300 options, integer attributes (year). Starting with two websites 6 languages each.
I've thought out two solutions to solve this problem:
Grouped / Simple product structure
We create a grouped product which is the container product, each condition will be a different simple product. We'll relate these products to the grouped product.
The nice thing about this solution is that is pretty easy to implement, we'll have to import the data in the correct way and all the information is exactly presented in the way we want.
New Product type
We create a new product type which can have multiple conditions, each with their own inventory. On checkout the inventory is substracted. The problem with this is that implementing the CatalogInventory model in this way probably is difficult and building a whole product type is time consuming and bugprone in general.
The advantage of this solution is this that there will be about 2-2.5x times less products in the system.
Others
Are there any other options to solve this? Maybe there is a module that does all this?
In conclusion: Of course I prefer the first solution but can Magento handle that? Does anyone have experience with this much Grouped Products? The system will have about 550000 products (grouped + simple) products in the system, what will be the performance implications of this? What happens when the site grows and we'll have twice the amount of products?
Without knowing more details I'd lean towards using a new product type or just adding the feature independently of product types if you have a use for configurable products (I definitely wouldn't try to duplicate the configurable product type). I'd disable inventory management and use some additional tables which hold individual item inventory with the per-item conditions and maintain a separate inventory that way. Use events and overrides to control the CatalogInventory stock status as needed. Creating new products constantly which are largely duplicates seems like a hassle worth avoiding if this is a long-term endeavor that needs to scale.
However, the Grouped/Simple method might be a viable short-term solution and appropriate if the project is in it's early stages and can't afford a huge initial expenditure. If well-planned, a script should be able to convert all of the old grouped/simple products into your new product type when ready to launch.