Let's take a look at your domain:
1) You have Recipes
Recipes are a collection of Ingredients and according steps to follow in order to get things done.
2) Ingredients have a name and perhaps a category (»vegetable«, »spice«, »whatever«)
I see no place where inheritance comes into play.
Does it make sense to refactor to an inheritance hierarchy early on, or is that a violation of the YAGNI principle?
In this case it is not really a violation of YAGNI. But it doesn't make sense. If you want tags on your Recipes, you could put tags in. If you want tags in your Products/Ingredients, put tags in. That's it.
I see at this early point no reason, why a recipe and an ingredient should inherit from something abstract which is taggable and/or rateable.
I would go for the simple solution first. Your goal is to write software, where one is able to collect recipes, invest a minimum of effort to get this done.
Add feature by feature and you will realize when it is time (i.e. »painful« enough) to refactor.
I feel like TaggableRatableTriviaEntity is a pretty bad name.
Yes. It really is. But you should not think in terms of object inheritance, but more in terms of behavioural inheritance - often named interface inheritance. Interfaces only provide behaviour.
Say you are doing Java, you have a class
Taggable and inherits only from
Base, which provides metadata (who created the item, when was it last modified etc.)
The problem with inheritance hierarchies is, that with increasing levels, the complexity increases.
So do yourself a favour and keep things simple. Leave abstraction out at first and add when needed.