Work with just maps, using namespaces keys.

Do you feel the need to “put” the entity model somewhere? Or just write unit tests as usual?

I think the closest to the modelling you are looking for is in my Datomic schema file.

But no, I don't have a list of valid keys anywhere. Some people use spec or Malli for that.

you may take a look at the structure of the https://github.com/soulspace-org/overarch code. I do have a domain folder with model and element namespaces. The entities themselves are just plain maps but there are a lot of domain specific functions, e.g. processors or navigation. I seperate these from the services and the outside world with a clean architecture. So far I'm pretty happy with the structure, even if it's not perfect I know where to look.

this is the overall structure of the namespaces (some recent additions missing 😕). each blue box represents a namespace.

Interesting, thanks! Of course overarch itself is documented with overarch 😄

eat your own dog food. 😄

A bit late to the party here but this is relevant to my interests. I'm generally in @U07FCNURX camp, just use namespaced maps and access them directly where you need them. But I've been on multiple projects where people on the team "feel" they "need" some kind of schema definition because otherwise it's anarchy. The question is what you do with that. In a statically typed language your compiler will tell you immediately if you fat fingered a property name. Most approaches I've seen give you some limited guardrails at runtime, meaning issues often only show up when they hit production, and it mostly checks the write path, even though issues on read are more common IMO. So now it's this extra thing you need to maintain and which itself can be wrong or out of date, so now you're getting schema errors on code that would've been fine without the schema checks...

> But I’ve been on multiple projects where people on the team “feel” they “need” some kind of schema definition because otherwise it’s anarchy. […], meaning issues often only show up when they hit production, and it mostly checks the write path, even though issues on read are more common IMO. So now it’s this extra thing you need to maintain and which itself can be wrong or out of date, so now you’re getting schema errors on code that would’ve been fine without the schema checks... I generally have the impression that things are put into Clojure because they are needed, and I appreciate that aspect a lot. I feel like that criticism can be pointed to “excessive use of schema definitions”: do you actually know why you need a schema for this now? Will introducing a schema actually help you solve that problem? :thinking_face: If an example is needed, perhaps a comment or a test solves that problem as well as a schema definition (assuming you don’t use the schema for validation in production).

#_ (greeting {:person/name "Magnar"})