You can have a util component with sub namespaces in its interface, https://github.com/polyfy/polylith/tree/master/components/util/src/polylith/clj/core/util the Polylith codebase itself, where you put the string utils function in interface.str.

ok interesting!

i'll be honest, i'm not convinced of this idea. i get why you're doing it (consistent use of architectural principle), but if how useful is it to make a very broad surface area of utility (i.e. domain-agnostic) functions swappable? i think perhaps a better way for this library code is to use Clojure's own principle: only additive, non-breaking changes

Thanks for your input. You rarely need to swap out the implementation of an interface for another component. In about 95% of the time (or more), a component will never have that need during the workspace’s lifetime. It’s still valuable that you don’t paint yourself into a corner, and that you know that all components can be swapped out if needed. Components make it easier to reason about the codebase and are valuable in themselves, so don’t be afraid of creating components even if you think they may not be swapped out by other implementations in the future!

i am enthusiastic about the architecture, and i'm keen to have at it. the vast majority of our code fits beautifully into distinct, unique components, aggregated into one or more bases, and served as distinct projects (e.g. high-traffic web components together on that fleet of EC2, all other low-traffic web on this fleet over here, background non-web work on that third fleet over there)

but, there are pieces of code that just get used flippin everywhere, like map-vals or date formatting or whathaveyou, for which an interface.clj feels redundant

for the code in 'domain' components, i love the interface.clj idea!

In that case you also have the opportunity to put the implementation directly in the interface namespace itself, without delegating to other namespaces.

right, that's true!

@U0509NKGK The consistency of using .interface everywhere and getting tool support for that is something that you'll find outweighs what you might initially feel to be "redundant". I too was initially very resistant to that approach in all cases, but having migrated several of our subprojects over to Polylith -- into two dozen components so far and rising -- I no longer see it as "redundancy" and instead see it as just a clean separation of concerns that has tool support.

I think this is probably the biggest mental hurdle to overcome when someone is looking at Polylith for the first time -- almost everyone raises it as an "issue" until they've actually worked with Polylith for a while.

nice, thanks @U04V70XH6 - i expect i'll end up in the same place as we get to migrating. i'd say we've 40-50 components to factor out, so it's going to take us a while. real fun work 🙂

We're at this point so far:

projects: 16   interfaces: 27
  bases:    3    components: 27

We've found that our "legacy" subprojects are far too coarse-grained and I think we got about fifteen components out of the first three subprojects we migrated...

we're at 150k source, 10k test, 10k repl scripts, across 5 repos - a common library, and 4 apps, one of which is used as a library by the other one. we're working on the monorepo conversion now. polylith will be next!

we'll start with one src folder, make four projects (for each app), and then start factoring bases and components from there

i expect it'll take us a couple years to get all the way through doing that though 😅

Cool and good luck with the migration!

thanks. great job with this by the way. i think you've just about nailed it.