• if I should refactor the code
• but rather how to refactor with a smart strategy.

I'm intending to publish this distribution on cpan and am reluctant of handling dependencies between spin off distributions, while I'm still in the design phase.

Dependencies between modules are much easier to handle, because they can all be part of the same distribution.

And that's also showing the current result of my meditation, I'll gradually split into several modules inside the same distribution.

As soon as I feel the urge to publish one sub-module independently I'd check if it's mature enough (documentation, tests, naming) and do so.

Like this I keep full flexibility to continue developing the main project without being hampered by premature publications.

I hope it's clearer now.

For those wondering about my terminology:°

• a module is a .pm file which is found in @INC and use 'd
• a distribution is a complex directory structure with Perl files and meta info

It's a module to create distribuitions, but is also available as cpan distribution.

The structure of the Distribution is seen in https://metacpan.org/source/DBOOK/Module-Starter-1.76.

The actual main Module is in https://metacpan.org/source/DBOOK/Module-Starter-1.76/lib/Module/Starter.pm

My main question now is how to best extend that directory structure to host sub-modules,

• An own top-directory /extra which holds stubs of these new distributions?
• Or just descending into my /lib/Module/Starter/ and adding new modules there?

( which is actually a strategy applied there, see https://metacpan.org/source/DBOOK/Module-Starter-1.76/lib/Module/Starter )

Most probably again a mix of both, I'll refactor into the same name space first, and will promote sub modules to own dists later on demand.

I hope my mediations are clearer now.

updates

°) https://www.perl.com/article/96/2014/6/13/Perl-distributions--modules--packages-explained/