There's no One True Way ™️ with Specs. You can put them where they best work for you. I blogged about how we used Spec pre-Polylith and very little has changed for us: https://corfield.org/blog/2019/09/13/using-spec/ Sometimes it's easier to have the Specs in a subinterface -- <top-ns>.<component>.interface.specs -- depending on where they need to be used from. Sometimes they'll be in the regular .interface, sometimes in a .impl.

I have read this post before 😄, and so interesting: sounds like you still have your specs largely defined in the namespace where the core functionality for those data-structures is implemented? That is how I'd done things prior. I'm assuming then that you expose the specs in the interface like you'd do the functionality then? in <top-ns>.<component>.interface you have definitions like

(ns <top-ns>.user.interface
  (:require [<top-ns>.user.core :as core]
            [<...>.spec :as s]))

...
(s/def ::user ::core/user)
...

If those specs are needed by both that component's implementation and by other components, it's easier to use <top-ns>.<component>.interface.specs as noted above.

(since otherwise you might want your .impl to require your .interface which would be circular)

right right, so you would consider it desirable that the specs are namespaced as :<top-ns>.<component>.interface.specs/<spec-name> then? (i personally think this makes sense/feels consistent, just confirming)

It depends on the intended scope, like any qualified names.

We tend to only use ::spec-name when those specs are not externally used. Otherwise we use a specific prefix that indicates their scope (at the domain level).

Or if the risk of conflict with other specs is high and using the full ns is the only way to guarantee uniqueness.

e.g., we have a bunch of :wsbilling/<spec> names that are defined in a few different parts of our overall ws.billing*.*namespace tree (part-base, part-components).

ahhh, thats very interesting to hear; I appreciate the feedback/info, this is useful meditation material