Hi @furkan3ayraktar! I returned to these same questions again and again in my numerous attempts to explain the Polylith approach and its benefits to the russian-speaking Clojure community in Telegram. What I’ve come up with so far boils down to this: 1. How would you describe Polylith? Polylith is a development-time architecture (sources) that organizes one’s codebase, supports its organic growth, and separates it from the deployment-time architecture (artifacts) in the most flexible way. Polylith gives one a generic structure and ontology for code organization and heavily relies on a set of well-established general design principles, such as encapsulation, SRP, low coupling and high cohesion, etc. 2. Comparison and compatibility with other approaches and practices. (I believe, this point is often overlooked.) Unlike other popular development-time architectures like Layered, Onion, Hexagon, etc., the basic structural unit of Polylith, a component, bears no extra semantics besides being a general building block. This allows any components to be combined with each other in any way, while maintaining the same fundamental restriction on interaction through the interface. It makes Polylith a lower-level architecture, which can be used in conjunction with popular language paradigms (FP, OOP) and other architectures (Layered, Onion, Hexagon) and design approaches (DDD) adding semantics to the components. It is also worth noting that this approach fits well with ways of organizing stateful components of a runtime system (Component, Integrant, etc.), REPL-driven development (by making the entire codebase loadable and accessible), incremental testing, as well as known deployment methods (monolithic services, microservices, lambdas, tools, etc.). 3. What problems did you have before Polylith and how do you think Polylith addresses them? In my experience, the larger a project grows, the more difficult it is to maintain good quality of its structural organization. Whatever semantic layers we agree to introduce, they, like any taxonomy, form an incomplete set with elements whose boundaries are blurred. Therefore, over time, the concepts of the layers begin to mix and interpenetrate more and more, but there is no force that would regularly resist this osmosis. Continuing the organic growth metaphor, the main problem with other approaches I’ve used to organize code as a system of interdependent components is that they don’t provide strong enough constraints to counteract this natural osmatic pressure. Polylith, on the other hand, refrains from introducing semantic layers and organizes the code on the most abstract entities (bricks), defining clear, strict and minimal constraints on them, as well as providing tools for automatically maintaining compliance to these constraints. This almost exclusively makes it possible to grow the code base of projects of any size in the most natural and expected way by a developer.

It’s a bit of a shame that such a powerful and elegant architectural approach for code organization is still in the process of finding its optimal unique selling proposition. It feels like we’re not touching on something deep and ineffable here, perhaps what @ztellman beautifully described in his book “Elements of Clojure” as tacit knowledge (love this book and recommend everyone to read it). It is possible that SW engineers with an established attitude towards the other approaches and practices I mentioned above: • simply don’t see any fundamental differences here, since Polylith is built on the same core SWE principles • do not clearly see compatibility opportunities with what they already have experience with (be it semantic architectures, DDD, or something else) • lack tutorials that teach the way of making things with Polylith in small, step-by-step hands-on exercises I’m glad to see the great progress made by @tengstrand and the Polylith team in addressing this huge communication problem (revamped docs, videos, articles, talks, podcasts and high community involvement), but I have to admit that some aspects that I mentioned above are not covered yet and may continue to push people away.