Version control
Does that mean for multi-team you’d recommend using a mono-repo?
If any kind of sharing and/or communication between the systems i going on, then you will benefit from having all the code in a single repo (workspace). A workspace should aways live in its own repo.
If more than one system is using a component, then it will help you get rid of code duplication and encourage reuse.
Because Polylith is an architecture that focuses on giving you as a developer the best possible development experience, it allows you to have different setup locally and in production. If you want, you can run all your systems as a single monolith in your local development environment that is executed by a single REPL. This will remove the need for mocking and simplify how you set up your local development environment. To be exact, no setup is needed at all, everything is just code running in a single REPL!
State
So where would that code live, if not in a base or a component?
Also, does that mean your bases and components never accesses any datastore? Or require session management?
I think I was unclear here. What I tried to say was that each component and base is just a collection of code that is later put together to form one or several systems. Let’s give an example. Let’s say we have the variable (def v (atom nil)) and the function all-cities living in the component c that when called for the first time checks if v is initialised, and if not, calls the database (by calling component database) and then reset! that atom with the values retrieved from the database. The next time function all-cities is called, it can use the state of v that is now already initialised. That’s an example of how you can handle state in a component or base.
Version control
But they both have an interface which could change no? And since each component is its own project and artifact, I’m not sure I understand how it’s managed without versions?
At least in Clojure, we don’t build single artefacts of our components and bases, we just ship systems. Each component and base that has changed since the last successful test or build will be AOT compiled against the workspace interfaces but that is just to ensure they conform to all interfaces.
It’s possible that in a future release of the Leiningen plugin, we will support AOT compiled components and bases that will need version numbers and be built and stored as JARs and used as libraries. If you implement Polylith for e.g. Java, this would be the way to do it.
Because all the code lives in the same workspace and repo, all the code will always be in sync. The reason is that every time you run the build command from the plugin, all affected interfaces, components, bases and systems are compiled and their tests are executed. The test command will give you the same level of confidence, but will not build the systems.
Every time you deploy, the plugin will know what systems have been changed since the last successful build, and therefore build those systems based on what is currently in the workspace. So if system s has the base b and the components c1, c2 and c3, and only c2 has changed since the last successful build, the whole system s will be marked as changed and in the end, be built and deployed (only c3 will be compiled and tested, not b, c2 and c3).