I know spec is maybe too new for idioms to develop but is there a clear answer to having :x.specs.user/email, :x.specs.user/password and then :x.specs.user/user for the whole user entity or is :x.specs/user a better name for the "entity", what's everyone's preferences here?

(ns x.specs.user
  (:require [clojure.spec.alpha :as s]))

(s/def ::username string?)
(s/def ::password string?)

(s/def ::user ;;or is :x.specs/user better?
  (s/keys :req [::username ::password]))

I'm personally convinced x.specs/user is clearly better than ::user which expands to :x.specs.user/user, just trying to get a second opinion before imposing my will on others.

We have been doing something similar to :x.specs.user/user in your example. It seemed like a natural choice at first and it quickly became a shared language across the team.

Same pattern you suggested: always the last s/def of the file and one ns per entity.

I’m also not sure if this will evolve into an idiom but surely has made the communication in our team much easier.

thanks for the input!

There’s an interesting side-effect that’s been great for the specifics of our project. We receive entity names from a remote system in a simple string. We can then convert the string into :x.specs.<string>/<string> and boom: we have our spec 🙂

@lucascs awesome yeah that's basically what I'm going for with the overall project set up but is there a reason you go with :x.specs.<string>/<string> instead of :x.specs/<string> for the composite entity at the end of the file? Because what you're saying could be done with either of those options just as easily right? (Sorry to painfully over analyze small details here)

Indeed it could. In practice the reasoning behind our choice was purely aesthetics. Kind of “everything related to the user entity is namespaced with :x.specs.user.” Otherwise we would need to always have the entity itself as a bit of an exception (defining it with :x.specs/user instead of autoexpanding with ::user).

Pretty much a personal taste thing

From a communication perspective, it’s one less cognitive level.

cool thanks again 🙂