Clojurians Log v2

Hi, i’ve a question on spec and it’s ramifications architecture wise. I’m working on a ‘clojure all the way down’ system with clojurescript for frontends, clojure services and a datomic backend, and basically commands/events as the primary communication mechanism. I’m applying clean, etc principles to my services, isolating biz logic, yada, yada. I’m taking advantage of spec for data throughout, but I’m wondering about the potential tradeoff/issues in terms of coupling. While all the components are pretty loosely coupled and I just pass data around, that data is described by a common library of specs, that they all reference. It is pretty nice that say ::account-number is described and can be validated, etc. consistently everywhere, but I worry that this form of coupling may have some eventual downsides. Any thoughts on pros/cons/alternatives?

That's a keen observation. I think the core team have been encouraging folks not to over-spec-ify your systems.

There's some balance between too brittle and too generic

well this particular example does not seem over-speced

indeed, creating a single spec that can be validated on client and server is the whole benefit of using Clojure in your whole stack

I would look hard to spec values that are passed between components and maybe the fns that produce and consume them, and not very much about specing the impl fns within each component.

Thanks guys. yeah I’d been doing it already (client/server specs) in simpler apps. But now that this is graduating to a larger architecture, values flowing and all, just trying to think through the ramifications. and yes @donaldball to your point, I think the ‘internals’ for say service x, would be spec’ed if at all, with in that scope. These ‘global’ specs are really there for the data (attributes, messages,etc) I’ve just been making myself think through it as I went through the Canonical Data Model hell back in the day on several projects lol, but spec is a bit of a different animal