I was listening to the podcast and I'm not sure "pure data model" is the best name for the approach. As I understand it, the approach is built around creating an interface and then writing your program in terms of that interface. This approach is really useful and can be used with or without an underlying data model. However, if this approach is used with the goal of hiding the underlying representation so that the underlying representation can change, then this is not a data model. Hiding the internal representation means that the representation is no longer semantically transparent. "Changing" the data model means that the semantics of the representation is now coupled to a specific version of your program. The whole point of a data model is to give meaning and semantics to a representation that endures over time. If the number 42 means something different tomorrow or has a different representation, then that's not really a data model. I think this is self evident for scalars like 42, but it's also true for more complex values. If you have a flow representation that means something different depending on the version of your program or requires a different representation to specify the same logical flow, then that's not a data model. That's not to say that the approach is inappropriate (it's actually an orthogonal decision). It just seems like "pure data model" isn't the best name for the approach.

What came to mind while listening to this was what is referred to as stratified design in SICP and presented in a really accessible way by Eric Normand in Grokking Simplicity. In fact, Eric has a talk where he makes exactly the same point of not littering the code with get-in paths, and instead "hiding" that away in a namespace that's about a particular domain concept. It was interesting to me to hear a similar take on the same concept, just using different words. It adds a bit of weight to the idea to see different people landing on the same approach

https://youtu.be/Sjb6y19YIWg?si=VM7zJ7NKdZ-FXtQ_