Clojurians Log v2

My 2c, having not dug too deeply (watched the video): Assuming we're talking about a Clojure system, I'm not really seeing what Polylith offers me other than a set of code organization rules that I could also (arguably more easily) implement with Clojure namespaces: put components under project.components.* with public functions as its interface (as @seancorfield suggested above), and put bases in project.bases.* (although, at this point the bases segment becomes kinda superfluous). To get the same Lego-block composability you can implement the same interface in different components (ns's), and swap out the ns's as necessary. If you require a more formally defined interface, it seems like we're talking protocols. Having an (automatically) enforced organizational scheme certainly has merit, because it removes that "freedom" from individual devs. It's like enforcing clj-fmt formatting in CI; you don't need to think/worry/argue about formatting ever again, because it's fixed and taken care of for you. It seems like Polylith possibly provides a similar kind of stability for code layout. OTOH it looks like this pattern adds a lot of overhead and boilerplate, where there is much less with "normal" namespaces.

@clojurians-slack100 Yeah, this is part of what I’ve been discussing with @tengstrand — Polylith comes across as a set of naming conventions and directory structures but now that I’ve spent some time with it, I can see it’s more than that: it’s just not being communicated very well…

It took me a while, using the poly tool, to see what they’ve really achieved here — and the structured naming is just a small part of what makes the tooling possible… and it’s actually the tooling that I think is more important (and it needs certain conventions in order to work).

Good to hear! Would you now say you're now convinced that the benefits outweigh the added overhead?

I wouldn’t say I was convinced of the “whole plan” but there are interesting elements that are clearly useful.

Nice. Is there something specific you'd recommend I look at for those elements, or is using poly the best way?

The incremental testing is very well thought out. The whole tracking of dependencies is pretty good. The constraints that poly checks about how bases and components (and, I think, projects) all interact with each other is consistent and well thought-out. It's funny, we had a couple of SDK subprojects and we initially mandated a bunch of rules about which subprojects could depend on each other in order to keep separation of concerns -- and Polylith formalizes that and enforces it beyond what we thought was useful.

At work, we've developed the incremental testing and the coverage testing (i.e., testing every component necessary when we build a specific project) -- but in a somewhat ad hoc way, because our repo doesn't have the same level of structure as Polylith.

What I'm still trying to ascertain is exactly which parts of Polylith are "important" in their own right and which are just "ceremony" 🙂

Sounds interesting. Thanks for the details.

Good morning guys! I’m glad to see that @seancorfield appreciates the poly tool. Let’s start trying to answer the last question: what parts of Polylith are important and what are just “cermony”. The short answer is that all parts are needed. • libraryused in bricks (components and bases) and projects to reuse globally shared functionality. • interfaceenables us to swap out implementations (components) in our projects. • component a piece of composable and reusable functionality that implements an interface • base exposes a public API and is the bridge between the consumer/user and the service/tool. A base is often the base of an artifact (project/service/tool/artifact) and allows us to change how our functionality is exposed in production by choosing what base to use for each project. • projects it’s in the projects we decide what concrete building blocks (bases, components, and libraries) to use in each deployable (e.g. service/tool/library) and are used in our test/stage/production environments. • development we separate the development project from other projects and the reason is that we want to support the best possible development experience as possible, a single REPL. The profile s will also help out and is part of the dev experience. • workspace is needed to support incremental builds, allows us to easily share code between projects, allows us to have a single development project that is always up to date with the latest code, and guarantees that we always use the latest code in our deployables. And yes, the workspace directory structure, where every concept is structured consistently allows tooling to be created like the poly tool by using https://en.wikipedia.org/wiki/Convention_over_configuration. The outcome from all this is that you can postpone how things are executed in production and instead focusing on the domain in dev, and postpone (or change) decisions on how to execute things in production without affecting the development experience. #polylith

I also want to elaborate on “…and the structured naming is just a small part of what makes the tooling possible… and it’s actually the tooling that I think is more important”. We started out using Polylith without having a tool and after working with Polylith for years, I just want to say that the tooling support is not the important thing here, it’s the Lego-like way of working with code and the way you solve architectural problems using Polylith. The tooling support is very convenient and shortens the feedback loop, and allows other tooling to be build around it (e.g. build tools, code generation of documentation, and so on…) where tools.deps is a really good fit for achieving that. We also believe that using a https://martinfowler.com/bliki/UbiquitousLanguage.html for software design has a huge value when it comes to communicating ideas and to e.g. understand a new codebase and to have clear definitions for all the above concepts shouldn’t be underestimated.

We have now updated the first page of the high-level documentation. Please have a look and give us feedback if you like @smith.adriane and @seancorfield. We have also updated the https://polylith.gitbook.io/polylith/conclusion/faq with several of the questions from my answers here (at the end of the FAQ).

I think those changes definitely help.