Replies: 9 comments 5 replies
-
Hey! Awesome issue @Arminek, thanks! I have a couple of thoughts/ideas related to this:
Physical products:
Digital products:
To better understand holarchies, you can do a quick mind puzzle: Would a concept of a white Witcher t-shirt with size S exist without a concept of a Witcher t-shirt product at all and of course the white variation of it? Same goes for digital products, BitBagCmsPlugin would not exist if Sylius Core does not exist etc. It's an useful check for verifying holarchies. Each holon (lower) also transcends (goes beyond/adds more depth or value, you name it) and includes the other (higher) holon. It's true for both t-shirts and Sylius', etc. Another interesting example would be a novel, which itself is a Product but its softback copy, hardhack copy "anniversary edition" and e-book version for Kindle are also Products. You can check here that the novel itself has some VALUE but a different version of it, go beyond that value and add something "on top". I am yet to find something of value that would not fit this model but I am very keen to have it challenged. :) Currently, it could be cumbersome but if we introduce a new model "Offering", which would be a combination of product, price, timeframe and maybe other rules (like a customer segment/group, specific market, etc.), it would be easier, cause only Products which have some Offering are sellable/exchangable, while others are just intellectual property.
For a physical product, it would be a specific The Witcher T-Shirt (Black/M) that is laying in the Lyon Warehouse, section B, shelf 48, position 5. Or a specific t-shirt we shipped to John Doe in Boston that is now going back to us cause he is doing a return. And it's different from another Product Instance of a the same t-shirt, but size S that he has ordered for a friend and it's ok. For a digital product, well a Product Instance could be hbx.com (an instance of Product: Sylius Core) or bakken.nl (instance of Product: Sylius Plus). I was plying with the idea of tying it to licensing but it's actually different, cause you can:
So long story, short if we want to deal with intellectual property and licensing properly, we would need an additional model IMO. What are your thoughts on this? (PS. Yes, I will get the book, one day!)
As a merchant, I offer you some products and if they are physical, I offer a Service: Shipping, the holarchy (yes!) could look something like this:
All can be performed, including the generic "Delivery", cause if you care about the customer's experience, if all shipping providers fail, you can rent a bike or helicopter and still make it. In the end, the customer just wants to get it. :) Or our (Sylius) consulting services:
Each adds more depth (in that case detail and focus), all can be offered, etc. So, in theory, we could squeeze it into Product model but something is odd to me about this idea, not sure what yet because I see a lot of similarities. That being said, in the case of a service, we talk more about specific "Service Delivery" (like in consulting/development delivery process, etc.). Also, the other value ingredient that I see (except Product, Service and Licence) is Relationship but I leave that for another long post. :))) We could consider extracting something common out of it but let's make it an exciting discovery through experimentation process rather than guessing! |
Beta Was this translation helpful? Give feedback.
-
I think for people to be able to grasp this (at least I am talking for myself here) and thereby contribute here, it would be beneficial to add some scenarios where this feature will make so much sense |
Beta Was this translation helpful? Give feedback.
-
Well if it is time to re-think a product then what about addressing products with decimal quantities and different units? |
Beta Was this translation helpful? Give feedback.
-
Hey Sylius community! Very good idea @pjedrzejewski to have a holarchical structure for products with many levels 👍 From my side too I have several ideas:
|
Beta Was this translation helpful? Give feedback.
-
I would like to point out YAGNI: https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it Whereas the global consensus is that you shouldn't be basing decisions you need to make right now on things that you think you might need in the future. So if the discussion is currently about adding a way to ease the use of "offers", we shouldn't be talking about all sorts of other things. Instead when it gets to that point you can decide to rework what you have in a new major version so there's no need to be scared of BC breaks etc. Instead of complicating things, it might be better to first define exactly the use cases you want to address and take it from there (like @loevgaard pointed out). Then maybe the patterns will make more sense. Right now it just kind of seems unclear what exactly the purpose is of adding this additional complexity, I'd say this goes for both ideas. Also instead of referring to a book on the Polish Amazon shop, it would be better to refer to for example wikipedia: https://en.wikipedia.org/wiki/Archetype_pattern so that if people are unaware of the pattern they can quickly get a grasp of what it means without having to buy and read a book about it. Personally I think there are bigger issues to solve first, but that's more of a timeline thing. |
Beta Was this translation helpful? Give feedback.
-
I will prepare some stories that will show examples of using this concept & the problem that we want to solve. Stay tuned 💃 |
Beta Was this translation helpful? Give feedback.
-
Is there some thought on using product types (with attribute sets) as a way to make it easier to create offers? Here are some cases: A discount on all pants in the color black or orange (but not shirts in the color black, or shoes in the color orange) |
Beta Was this translation helpful? Give feedback.
-
Guys, i want to take a simple approach on this one: what problem are you trying to solve with this?🤔 |
Beta Was this translation helpful? Give feedback.
-
@pjedrzejewski, it is a great step forward that you are going to include ES support into Sylius by default. I have some experience with implementing different strategies of pricing using ES. Could you please put light on how you have going to deal with multiple different prices for the products and still support complex ES aggregation (e.g., nested aggregation) and sorting of prices? Also, it would be interesting how you are going to keep multiple prices support on MySQL. Could you please share your vision about ES and MySQL schema structure? |
Beta Was this translation helpful? Give feedback.
-
👋 Hello, Sylius community,
According to our roadmap, we have started thinking about tackling these new features. These are kind of related to each other:
So yeah, we would like to start with stop & check. Let's review what we already have inside Sylius.
From Archetype Patterns perspective in Sylius we have covered (not fully):
When we have to go through the new features which we plan to introduce. We have noticed that there is a missing core concept that will allow us to do it in a more elegant way. The missing archetype pattern is called the Product Catalog.
The Product Catalog archetype - represents a persistent store of product information used in the selling process.
So we want to introduce a new core concept of offers inside sylius standard. But what does it mean from a technical point of view?
Offers will connect few things together:
We are thinking about introducing
OfferSearchEngineInterface
with default implementation based on elastic search (ES in sylius core by default).We believe that features like:
Will be much easier to implement using this pattern.
This is just an idea. We would love to hear our community 😄
I want also to invite you to this board if you are interested in topics related to the future sylius architecture.
Beta Was this translation helpful? Give feedback.
All reactions