TADA is a Clojure(script) library for declaratively modeling the public functions for a program's domain model.
The main motivations were:
When trying to write applications "securely," certain functions can't trust their inputs, and must check they are of the correct types and that the action is allowed given the state of the application. It's a huge pain to write every function at every layer defensively. A project often needs to decide where to "draw the line" for being paranoid vs. trusting the inputs; for web apps, it's typically whatever gets exposed over HTTP that is considered untrusted. TADA tries to make it easier to write this layer of functions "correctly" from a security standpoint.
From a functional-programming domain-modeling perspective, most applications can be modeled as a collection of "public" functions - the ones that are triggered by external behaviour (ex. a user action). These could be organized in various creative ways (such as REST), but in TADA, it's a flat list with keywords as ids (the events themselves can be declared in multiple namespaces).
TADA events are purposefully separate from HTTP end-points. IMO, too many web apps conflate HTTP and their domain model. Exposing your application as an HTTP API is as an implementation choice. With TADA, you would declare your public "events" and then generate your HTTP API (and potentially, generate an alternate API). As a bonus, you can test your domain separately from your HTTP layer (which is what we usually do for our system integration tests and seed files).
☙
The TADA pattern was extracted out of several apps that we had written at Lean Pixel. It started out as a library called decant, but as I was preparing my talk about the library at ClojuTRE 2019, we renamed it to TADA. (James heroically finished off a few key tasks the day before the conference, because I was too jet-lagged to do anything.) Back then, I had the ambition to also include entity modeling as part of the library (which I mention in the talk), but nothing solid is ready yet (I have been incubating several prototypes in some applications).
☙
In some ways, TADA is just a "function on steroids" maker. We could make a (tada/defn ...) that does the same, but I'm not a fan of macros. But, we could make a (tada/fns) macro that injects functions for all the events.
In some ways, you could just use reitit to achieve something similar (with malli middleware to check params, custom condition checking middleware, etc). It should be easy enough to write a function to convert the TADA definitions to reitit configuration (that's the power of data!).