Or how can one map the previous concept of services to a concept in the Polylith architecture?

One or more base (most often only one base) + a number of components can be put together in a project from where we can build an artifact. This artifact can be e.g. a stand alone command line tool (like the poly command) or a service. The base has the role of connecting the outside world, e.g. a command line interface or a REST API, with the code that performs the task, e.g. executing a CLI command or a REST endpoint. Bases and components are just building blocks, and you decide which kind of artifacts you want to build from them (e.g. a service).

The question in particular has to do with the naming pattern like I highlighted in the question

Or is it just better to box them up and expose the interfaces from separate namespaces?

If component-model is only used from component-resolver then it might be an idea to keep it inside component-resolver in one or several namespaces (where the top namespace is named component-model if more than one). You have a big freedom to divide your components in namespaces, but also to split your code into several components. It’s very much up to you what you think is best, and you can experiment a bit in the beginning, and also get some inspiration from other Polylith codebases, e.g. the https://github.com/polyfy/polylith codebase itself or the https://github.com/seancorfield/usermanager-example/tree/polylith. I would advice you to drop the component- prefix also.

We have a separate section about naming https://polylith.gitbook.io/poly/misc/naming.

Yeah, the component- was a just placeholder for the domain concept e.g. invoicer-

@U0HJYDTP1 I personally think it’s fine to do what you’re doing—there’s always a chance component-model could be used in another base without component-resolver in which case you have fewer dependencies and less being imported into one of your bases.