I wish there was a book I could buy, titled "Data Modeling with clojure.spec".

Here's an example of a practical question. Should I do (a) or (b)?

;; A:
(ns testing.spec
  (:require [testing.id :as id]))

(s/def ::id ::id/id)
(s/def ::data-structure (s/keys :req [::id]))

;; B:
(ns testing.spec
  (:require [testing.id :as id]))

(s/def ::data-structure (s/keys :req [::id/id]))

You should do whichever one matches your data

Hence my wish for the book 🙂

personally I would define the spec for the id in the same ns as the id

unless the testing.spec ns is the only place you plan to refer to it

:: is a spec for an UUID in a certain form, this gets used all over the place. Question is, do I alias it locally using ::id? In other words, who "owns" the ::id definition?

And Alex's Zen Master answer is actually spot on. My current thinking is that I should use local ::id, since this is really a property of the data that I'm defining locally, and only coincidentally an UUID whose properties are defined elsewhere.

I think about it as two levels - it’s useful to have specs that capture common type/shapes/formats domain things - phone numbers, invoice numbers, etc. then there are entities that collect attributes and those may have their own names. Like you have a :foo.domain/phone and then you have :foo.company/phone

(and the latter would just be an alias for the former)

that adds weight (and there are some bugs around overriding generators for aliased specs) so it may or may not be worth it

phone number is probably something with extra constraints, but if you have something adequately represented as int? then I would not pull it out as a domain type as that doesn’t seem worth it

some day we’ll consider doing a 2nd edition of Clojure Applied and think about some of this stuff :)

Right. This is similar to what I've been thinking, too.

A book would be very welcome. I would really like to learn about how people approach modeling data, preferably from people who actually build real systems. Spec seems very flexible, but I found that if you deviate from a certain path, you'll be swimming against the current (for example, if you insist on using unqualified keys).

BTW, I solved my coercion problems for the time being by judiciously removing every s/conform from my code and writing a tiny piece of code that maintains registries of coercions (multiple registries, as it turns out: one for converting to the domain model, and one for converting to db form). This seems to work very well and apart from limitations of unqualified keys in specs solves the problem for me.