a) Data is just data, divorced from behaviors, and functions (not methods) manipulate data. This is really just old-school functional programming.

b) Data is represented by hashmaps, and are extensible - if the data gets richer over time (= more keys in the hashmap), functions that used to work on the previous, poorer data still work on the new, richer data. In other words, each key of a hashmap is automatically an interface, and data satisfies interfaces depending on which keys they have (structural typing).

Now, this interface mechanism is a bit sloppy if keys are just string identifiers, but this is overcome by namespacing keywords (which has its own syntax, ::keyword), thus removing the risk of the same name being used for different purposes. This idea is most clearly articulated in the core.spec library, which encourages you to establish a 1-to-1 relationship between a (namespaced) keyword and a spec (https://clojure.org/guides/spec#_registry).

Previous dynamic languages have always used hashmaps to represent data, either directly or indirectly. But once in the land of high-level abstractions, they would revert to "canonical" Java-style OOP (Python and ES6 being the most notable examples). Clojure seems to be the only mainstream-ish language out there that uses -- or at least aspires to use -- hashmaps as a real abstraction mechanism rather than a convenience.