I don’t have any commercial experience and I have made only simple apps as my hobby and education, and I have just write one very simple application using dry gems, so I am not sure my thoughts make any sense, but I want to share them.
I like the idea of small function-like objects because I don’t know how to create and organize bigger objects. With small objects I don’t have to think how to design them, because if they do just one thing, then it is just a one way to design them. I have noticed that with this approach I have to use many objects (like 40 for a simple console calculator), but most of them are reusable control flow objects and only about 20% of them are objects that I must create from scratch (and they are very simple).
This small objects are connected in a dependency tree graph and it is not possible to track this tree (it is growing and changing) without having a graphical image of it. I use a mind map tool for this.
dry-container is very helpful especially because it can stub objects during integration tests.
dry-system is good because it automatically registers objects. But this alone is not very helpful. The best thing is auto-registering plus auto-injecting. Because those things together allow to create objects that are close to root of the dependency tree automatically.
And I don’t know yet if it can automatically register for example a Hash or Array or it must be always a custom class defined in a file with a proper name.
dry-auto_inject is IMO the less helpful. I think I can do the same thing with just writing regular initialize methods with default arguments (taken from a container). dry-auto_inject has only two strategies of passing arguments and it forced me to rewrite a class because my class was expected arrays of objects (they were registered by the container) or regular args mixed with keyword args and I think dry-auto_inject could not handle those things.