Yes, I think we’re in full agreement. My current clients build these types of systems. I mean there’s always some more logic than just store data and display it, but nothing as involved as e.g. a banking system. We actually briefly deliberated about pure model data structures, but they didn’t seem worth it for us.
I absolutely agree that in more complex cases using the underlying storage view for domain model won’t be optimal. I mean, you can always hack around it, but this will bring needless complexity in the app code. So, yeah, in such cases having a pure domain model decoupled from internal db representation is definitely a good choice.
To be clear, this isn’t a shortcoming of Ecto, but rather it’s property. Ecto makes IMO a great choice to keep schemas very close to the underlying db representation, which makes things simpler in the beginning, and is sufficient for smaller domains. For anything else we need to do our own work, and I don’t think that any library/framework can help us here.
So I just wanted to point out that starting with the pure model IMO is an overkill for many projects, and also that such approach needlessly raises the bar for the people who are just starting to use the technology.
