Please add your comment here!

Also, if you have another name suggestion, then we’d love to hear that too! 🙂

Hi guys! I have been learning polylith since two days and I love it! 🙂 For a new comer, base maybe difficult to understand without reading the documentation! I’m wondering if a base can be used in different projects ? gateway is more understandable. What about service?

Here’s some suggestions from me: api entrypoint baseplate

I would appreciate descriptive names over generic ones

We used the word service earlier for what we today call project. A project can be a service if you put the right combination of components, libraries and a base in it (the base exposes the code as a service) which is an indicator that it’s not the right word for the concept @UHZPYLPU1.

We discussed api and we came to the conclusion that a base consists of both an api and a thin implementation that delegates to components. A component has a similar relation to its interface, which also is why interface is not the best name for a component @U018VMC8T0W.

I should have mentioned that your other two suggestions were just fine! 😃 @U018VMC8T0W

I don’t think gateway is any more descriptive than base — and I think most uses of gateway in IT refer to something that wraps an external service (often a database, as in data gateway). See https://martinfowler.com/eaaCatalog/gateway.html for example.

I would have suggested service if it didn’t already have prior use in an earlier version of Polylith. I like entrypoint but it’s overly verbose. I agree base is somewhat nondescript/opaque and potentially confusing for newcomers but I’m not sure what to suggest as being better.

Good input @U04V70XH6!

A question about the cardinality of bases: is the expectation that a project has exactly one base (and multiple components) or are there common situations where a project might have multiple bases? (asking in the context of naming and whether cardinality can play into it)

We have only used one base per project so far (none for libraries). I guess it could be relevant if you have huge APIs (e.g. REST) where different teams are responsible for different parts of that API, but that’s not something we in the Polylith team have any experience of.

I'd stick with base, it doesn't take long to learn what is meant by the name base. It makes sense to me in the context of the lego analogy. Personally I never had any issues understanding what a base is.

As someone who has been putting a lot of time in to moving a project in to a Polylith structure, I'd rather things stay as they are unless there are large and obvious reasons as to why they need to change.

Nice feedback @U0L5T5DHP, sounds reasonable.

If the “normal” cardinality is one base in each project, then I would say stick with bases at this point as it makes sense with the LEGO analogy: each project is built from one base and a bunch of components. In general. Even if a base is reused across multiple projects. And even if occasionally a project somehow combines multiple bases.