With things like EAV and Datalog, you still end up coupled to the names and kinds of facts that you store and the relationship between entities in your structur

With things like EAV and Datalog, you still end up coupled to the names and kinds of facts that you store and the relationship between entities in your structure. It turns out that there can be many ways to store facts about an entity, and model the relationships between them, which may be convenient or not depending on the context. But it does help in that it can much more easily evolve with the kinds and shapes of data that you need to store in your app as your app changes and grows. More abstract constructs like lenses can help with this as well. By building lenses for reading that can transform to a domain context structure from your global program state, you can keep them relatively decoupled and ensure all of the glue lives only in those lenses. I'm undecided on the utility of leveraging lenses for mutation as well; on the one hand, mutation allows one to operate strictly in the local context, but on the other hand, it requires your lenses to be truly bidirectional (which I think is harder in practice than in theory), and counts on either synchronous sync of local state and global state _OR_ eventual consistency with the rest of the app. Going a more CQRS-esque way like Redux/re-frame allows you to not rely on the bidirectionality of your lenses and also ensures consistency in that local state is only ever driven by changes to the global state.