In object-orientation you generally tell an object to do things instead of asking it for data and trying to do it yourself. In other words, a very simple solution is to ask the object to persist itself.
You could also call this polymorphism, if you have different types for different states and still want to tell the same thing to each of those (i.e. persist yourself).
Ideally though, you wouldn't even necessary need to ask. An object should persist itself as part of the business-case at hand, as needed. I mean why would you assume that an object needs persisting from the outside? The object already knows everything it needs to know about itself.
This clashes with some interpretations of DDD, where the "model" is just data structures and "repositories" routinely get data out of objects and persist them without the objects involvement.
About the "functional DDD" book.
I've written enough Haskell (and some functional Scala and Kotlin+Arrow code) to be somewhat familiar with FP. I'm not familiar with the book, but I did look at the code. I do not like that code.
The big idea (in my opinion) of DDD is to concentrate on the domain. Let the design be about the domain, the common language, instead of technical stuff.
Now just look at the names on top level. There are appr. 20 words in there, not counting repeats. About 2 of those connected to the use-case: "PlaceOrder" and "Pricing". All others are technical, like: Api, Dto, Implementation, InternalTypes. Now sure, some scaffolding is always needed, but 90%?
Now try to find out what this code actually does. What is the business case? It is really hard. There is a "PublicTypes" file. That only contains data structures. Which is implementation detail, noone cares.
Third, what is "UnvalidatedOrder" anyway? Is that really a thing? I suspect it is just a technical thing and has nothing to do with the common language. I mean it is really fancy (it would be even more fancy if Unvalidated[T] would be a Monad btw.), but it is a technical thing. Technical things are not cool in DDD. Neither in good OOD.
That is just from 15 minutes looking at the code, so take this part about the book with a grain of salt!