The problem I encounter everywhere is that the VOs are Ecto schema structs which, wherever they’re used, couples all the storage-agnostic logic to the database structure.
krasenyp
yordisprieto
As far as I can tell, Ecto.Schema and Ecto.Changeset isn’t about database per se. I understand what you are saying, and definitely people should be careful. While also, it doesn’t hold water. The Ecto.Changeset is about validation, and Ecto.Schema is about structs, mappings, and Ecto.Type is about a shared interface around marshalling, unmarshalling.
Ecto.Repo, and Ecto.Query; maybe, it would be more about actual DB.
Being said, 
0
sodapopcan
They aren’t, and you can have separate schemas and changesets for your forms! In small apps I never feel this is worth it, but we do this at work with more gnarly forms.
Gotta call this one out as Changesets are not just about validation but also about, ahem, changes. Sure they go hand-in-hand, but so many Phoenix apps do a lot of parameter manipulation in the controller/LiveView layer before passing them to a changeset. I know it’s in many other apps evident by the number of people who ask how you deal with maps that may have string or atom keys… you don’t! You use the changeset API!
K, rant over.
4
Oddman
Please elaborate - I don’t see why? How do you otherwise ensure you get the appropriate structures/values whenever you depend on them?
0
garrison
My reply was a link to a very detailed answer to your question. But, briefly, you ensure they are appropriate as you consume them.
The transition state between two valid states is often itself an invalid state. If you approach this with the mentality that the state must be valid “at all times”, whatever straitjacket of a data structure you cook up to achieve this will necessarily be incapable of representing transitions. And then it is you who will be cooked, I’m afraid.
0
Oddman
My experience has proven otherwise, for over a decade. If I understand you correctly, you’re saying that if I accept an argument, I then validate that argument in every function that expects it? Why would you do that, when you can do that in one place, and one place only, using the value object pattern?
I also read the article, it’s front-end focused. To that point, I largely agree with the author, and it was a good read. However, we’re not talking about frontend, here - we’re talking about value objects on the backend. Perhaps I’m missing something, but let’s take the ID argument above - how would you handle that without a value object implementation in elixir?
IMHO, expecting a particular struct/value type solves the problem almost entirely. At the very least, when dealing with IDs from Ecto, you’ll never end up passing the wrong id to a function, say a relationship that expects that value.
2
garrison
I never spoke against this “value object pattern”. I only suggested that you free yourself of the mentality that data must be “valid” at all times, because that mentality will hold you back. Especially if you’re writing games, which are like frontend on steroids.
I think it would be easy to poke some holes in the value object idea (what if I hand you %Id{id: "evil nonsense"}), but I don’t want to do that because in the limit I think it would be an argument against type systems, and I don’t actually have a problem with type systems, so long as they are not accompanied by the aforementioned mentality.
If you have read and enjoyed the article then you understand the problem and my work is done, I have nothing else to add 
0
tfwright
You didn’t yourself make the point, but the article you linked is fairly polemical. It calls out an entire class of BE devs en masse and accuses them not only of not being well-equipped to handle types of FE complexity, but also poorly designing their own systems by insisting so much on validation. I don’t think the article does a great job backing up that argument. This passage seems to be the most direct treatment, and it’s still fairly vague:
The trigger vs memo problem also happens on the back-end, when you have derived collections. Each object of type A must have an associated type B, created on-demand for each A. What happens if you delete an A? Do you delete the B? Do you turn the B into a tombstone? What if the relationship is 1-to-N, do you need to garbage collect?
If you create invisible objects behind the scenes as a user edits, and you never tell them, expect to see a giant mess as a result. It’s crazy how often I’ve heard engineers suggest a user should only be allowed to create something, but then never delete it, as a “solution” to this problem. Everyday undo/redo precludes it. Don’t be ridiculous.
Maybe I’m missing the real point here, but this doesn’t sound like an average BE type problem. If this standard parent-child type relation, then there are plenty of patterns that don’t involve forbidding deletes, baked into most DBs in fact (do cascading deletes count as “garbage collection”?). Maybe it’s caching, which, yes, we are aware can be quite complex. But then I’m not sure how it relates to the issue of “intent” at all, since the user is not involved at that point.
The closest BE issue that comes to mind would be robustness in API design. Of course we want to try preserve the user’s intent as much as possible and even when we end up running into problems it’s good to be able to preserve that intent in the system so we can provide good feedback. But at the end of the day I think modern FE is just really complex with tons of user input being rapidly provided and so obviously validation is less useful and the balance is going to be a lot different compared to a web API.
But then at the end of the article the author seems to imply that internal APIs (BE/FE splits) are themselves a bad, or at least obsolete idea so
1
Oddman
Fair point, but I’m also not arguing for “valid at all times”, as that’s impossible. However, I think that’s for the most part, pure semantics. I’m a subscriber to the DDD approach where the business domain cannot be ALLOWED to have an invalid state at any time. This is enforced by strong typing and/or validation where required. This massively reduces bugs, and so my point about IDs and value objects are approaches to enforcing that validity of state.
I think arguing against that doesn’t make much sense, but of course you will have invalid state when a use submits a form, for example, and you have to manage that, but that’s a separate concern. It seems to me to be a bit of a strawman, honestly, or at least somewhat disingenuous - because it’s obvious. You can’t enforce valid state from a user, that’s why we have validation in place to begin with.
Your point about the ID part, what you’re suggesting simply wouldn’t be possible. The value object pattern enforces that (for example), the ID must be an integer, or a ULID, or whatever it is that makes sense in your system. Of course, a developer could certainly just create an id object without an actual valid id value, but the question then needs to be asked - why? Why are you doing this? If it’s for testing purposes, okay - makes sense. But are you doing this in code you’re preparing for production? Bigger questions would need to be answereed there, likely one of maliciousness 
2