Namespaces / Domain Modelling / Re-frame

[erikseppanen]

Discussions related to namespaces / domain modelling / re-frame / DDD have started in some issues/pull requests, like this one. Instead, we can have these high-level discussions here. Or maybe it's just me trying to organize my thoughts :)

I imagine this discussion could start at a high-level first, itemizing the different tools/practices we can employ to help with development.

[erikseppanen]

How do we organize things?

Namespaces
The most tangible, matching the folder structure. This is not only related to the namespaces we author, but also the namespaces of our dependencies. Function calls, etc. in a namespace can only happen if the namespace is included (:required). These relationships can be viewed in a dependency hierarchy, like clj-heira.

• Project structure
• Require/import
• mostly closely to what is called 'architecture'

Re-frame events/subscriptions
These relationships are free to be completely different from namespaces, because they are explicitly dispatched and received with names we invent. So they don't have to look anything like the namespaces, but they probably will to some extent.

• Subscription names and event names
• Register top-level subscriptions

Domain modelling
We may want to organize things more conceptually (because namespaces and re-frame are more directly associated with real effects), and use concepts like DDD's UbiquitiousLanguage and Bounded Contexts.

• Is this what app-db is? A: yes.
• For naming events in a way that isn't constrained by their namespace, related to what we've called fake or contexts
• Accessibility labels? This I'm not sure of, but it is interesting in that it might intersect with the domain used by QA.

---

Not sure how much work should be put into this, vs. organically letting them form. But we do spend some time in code reviews discussing and addressing/moving things, so some guidance/guidelines, at least, would be helpful.

It might be useful to connect/compare our domain with QA's, designers, status-go, status-desktop and maybe users (through documentation?). Or maybe we follow a domain that is already defined/used somewhere else...

HQ: review re-frame docs

[erikseppanen]

This PR takes an opinionated, light-weight (no clojure.spec) approach that follows these ideas:

• 'Is this what app-db is? A: yes'
  (app-db is literally the data model, just start giving it more deliberate focus and attention in the codebase)
• 'organically letting them form'
  (just start with namespaces that might benefit from it - no need to do everything all at once)