Thanks for the good read.

In Polylith we don't configure how the bricks depend on each other. As long as they compile in the development project, we are fine. All bricks have access to all components, or to be precise, all interfaces, and they are connected by using direct function calls.

Thanks! It doesn't matter much if a component depends on one or ten other interfaces, because they are all available, just like libraries that live in a global repository are. What's important is to create components that do one thing. The more cohesive components you create, the fewer the number of connections to other interfaces you get. That will also make each component easier to reuse. But sometimes a component is really specialised, and there is little chance that it will be reused. It still has a value to have it as a component, because it follows the same code structure as other components, which makes it easier to reason about.

I see your point. I wanted to point out that drawing the boundary line for a component is a work of art. For instance, you have component A that does one thing but depends on B, which incidentally depends on C, which depends on D ... such that in a case where a base wants to use 'one function' from component A, when shipping the base as a project, you will end up including B,C,D .. and bunch of other not so much relevant bricks. In this case, the easy references made in components can cause a huge add in size.

I see your point. If the size of your artifacts matters, then the need to have small components becomes even greater.

I had a hard time understanding the concept at first, but now it feels very reasonable. I don't think it's a problem with Polylith that you can inadvertently create components with many dependencies. Rather, poly deps make it easier to catch them. 🙂

@U7JHWBCS0 To think about it, it is similar to adding a npm library for a function inside of it, which happened to be dependent on other libraries. I came to think in that way, and agree to the point that it cannot be avoided.

@U01TFN2113P yes, that can cause dependency hell. what i want to say is that's idiosyncrasy of the modern software ecosystem (left-pad?), and one way to mitigate it is to use monorepo. in polylith, you may consider all dependency in project level, not in component level, by using poly libs which is pretty good i think. https://clojurians.slack.com/archives/C013B7MQHJQ/p1698126559607279?thread_ts=1698121700.690439&cid=C013B7MQHJQ

yes that helps indeed. My initial motivation for adopting polylith was primarily to reduce redundancies in codes by picking the very necessities, so that the bundle can fit for services like lambdas and etc. That comes as a gleeful side-effect, and I also got to understand it is not the best of what polylith can bring.

i see no hope in jvm for reducing lambda size 😂

Thanks @U1G0HH87L, great project and article! My .02 after just reading the article (never used Polylith, yet!): * Looks like the way to deal with "Secondary Actors" (say, a DB, or "Send Notifications" module) is to simply have a Component with multiple possible implementations. Right?. Now, one key point of Secondary Actors, I think, is that the Interface (port) is defined by the "application" (inner circle), and the external components (adapters) implement it. Is this separation allowed naturally by Polylith? * Polylith doesn't introduce any concept/mechanism to identify which components are Secondary "ports/adapters" vs internal to the app core. I'm wondering if there would be any benefits in doing so... maybe to enforce that "inner" components do not depend on "outer" ones? Maybe enforce that a "project" is "complete" (that is, all ports filled?). This depends on my prior point * Nitpick: The first time I read about Polylith, the names base and project confused me a bit. This article clarifies them well. They still feel unnatural to me.... I've got this same observation from a colleague: "bases" sit at the "top" of the stack? :-\ Maybe those points have obvious answers once I actually get to use Poly (and I will soon!)... just wanted to give you my first impressions from only reading about it. Thanks again!

> Now, one key point of Secondary Actors, I think, is that the Interface (port) is defined by the "application" (inner circle), and the external components (adapters) implement it. Is this separation allowed naturally by Polylith? A component is not connected to a specific application. That's the beauty of it, that a component can be used everywhere. It would be possible to add another layer of scope/restrictions, that can be checked by the a Polylith tool, but it seems that the community is quite happy without it. > Polylith doesn't introduce any concept/mechanism to identify which components are Secondary "ports/adapters" vs internal to the app core. I'm wondering if there would be any benefits in doing so... maybe to enforce that "inner" components do not depend on "outer" ones? The application core in Hexagon is allowed to depend on secondary adapters via ports. The same is true for components, that they can depend on interfaces, even interfaces that delegate to "secondary adapter components". So the level of restrictions is actually the same. In Polylith, you depend on interfaces, and in Hexagon you depend on ports, which share the same role, to abstract away the implementation. > They still feel unnatural to me.... I've got this same observation from a colleague: "bases" sit at the "top" of the stack? The reason for the name base is that it lives at the bottom of the "building", see James presentation https://youtu.be/Xz8slbpGvnk?si=FuJd1Y6XDrjdlEqC&t=489. If you search for "Lego base plate" you will be delegated https://www.lego.com/en-se/product/gray-baseplate-11024?age-gate=grown_up and if you have played with Lego before, you know that it forms the base of what you want to build. Hope this helped. Nice to hear that you will try out Polylith soon!

👍 thanks again