Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce a tree structure into the components and bases subdirectories #513

Open
marksto opened this issue Oct 28, 2024 · 1 comment
Open

Comments

@marksto
Copy link
Contributor

marksto commented Oct 28, 2024

Is your feature request related to a problem? Please describe.
Having the workspace components (and maybe bases) semantically grouped in some way, e.g. by purpose, by layer, etc.

Describe the solution you'd like
Introduce a tree structure into the components and bases subdirectories, so that the dir structure like this is possible:

...
- components
  - domain
    - domain-component-a
    - domain-component-b
  - services
    - service-component-a
    - service-component-b
...

Describe alternatives you've considered

  1. Support for multiple workspaces (see Add support for multiple workspaces #431 and Don't implement support for multiple workspace #470). Now reverted.
  2. The only workaround atm is prefixing the component names, e.g. "domain-component-a". This sucks a bit, since the separator options are limited to - and _, since a component name have to be a valid file name.

Additional context
Already discussed this feature in Slack channel and here as a partial alternative to multiple workspaces support.

@AlexMoskvichev
Copy link

AlexMoskvichev commented Oct 29, 2024

Hi. Want to support this issue.

I'm evaluating polylith for a few weeks now.

I've started trial project, structure in overall looks very good,
but I started wondering, how to organize components.
There is several aspects - number of components growing,
we have several layers of components - small utility components,
low level components, bigger components aka modules (but still components for the bases) etc.

As I'm new to poly, I can't argue for a specific solution,
but both adding tree structure (or at least sub levels) and
extracting lower layers to another workspace looks good for me.

The way of adding some prefixes to the component names I don't like very much.

I'm talking about a project with 50-200 components. For smaller number still nice to have add groups of components, but not that critical.

What are you think? Maybe we can add some metadata to the component's deps.edn or other config file and use them instead of relying on catalogs names?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants