Let's say I have a UserEntity, ProductEntity, TransactionEntity, These entities have their own repository and helpers class, Is it correct to treat them as separate features?
It depends on the domain you are working in. DDD is about organizing your code according to the underlying domain. You should structure the code by the bounded contexts of your domain. The reason for this is the single responsibility principle. Classes in a bounded context should only change for one reason. E.g. an organization that sales products usually also provide support for them. Classes in the sales context change for sales reasons while classes in the support context change for support reasons. This also means that you can have an entity with the same name in different contexts. Even the entity has the same name, like Customer, it has different relationships, properties and methods in different contexts and is a different class as this diagram shows.
Bounded Context, Martin Fowler, 2014
The term feature that you used in your question is a bit overloaded. So when you mean bounded context when you say feature you should separate them. If you just mean entity or use case, you should think about the bounded context to which they belong.
If yes, What about TransactionEntity which contains both ProductEntity and UserEntity inside of it? Is it okay to make one feature depend on other features like that?
Like I said above I assume that you mean bounded context when you talk about features. It is okay that bounded contexts have relationships. A dependency is one kind of relationship. When you introduce dependencies you always ask yourself about the direction of the dependency. That's what architects do every day, they manage dependencies. One good principle is the dependency inversion principle. Uncle Bob summarizes it as
Low level policies should depend upon high level policies.
Robert C. Martin
Applied to bounded contexts it means that a higher level (or more abstract) domain context, like customer management, should not depend on lower level (more detailed) domain concepts, like insurance quoting.
You can integrate two bounded contexts by using domain events. So when one context changes it emits an event. The other bounded context listens to this events and performs appropriate actions. You can read more about this in the book Implementing Domain-Driven-Design, Vaughn Vernon.
In short, the event mechanism might be implemented as a simple observer pattern or by using a message queue. Usually message queues are used to communicate between different processes, as in microservice architectures, but they can also be used as an event mechanism in one process.
I hope I could answer some of your questions and guide you to sources that will help you to understand DDD more.
