I prefer to just throw the state into a database. Each table has their own “repository” type that knows how to save/load models and then I have “manager” types that use “repository” types to compose larger, feature-specific domain models.

I usually just use Sqlite for it’s simplicity but I’m not opposed to Postgres via Docker.

The models in my project have several ways of doing it. On the server side, there’s a function that accepts data from the DB, and a function that accepts data from the frontend. Same with serializing. One function to serialize the data for the DB and one to serialize for the frontend. On the frontend, it’s simpler, since it only sends/receives to/from the server.

That’s mostly abstracted away in a top level class called “Entity”. It’s only if you need to do something special that you’d reimplement those functions. My data abstraction library is open source at https://nymph.io/ if you wanna check it out. It’s what runs my email service, https://port87.com/.

Models should contain or inherit their own serializers/deserializers.

Either put the generic serialization in a base Model class, or make the base Model class defer implementation to a reusable Serialization helper class, preferably an off the shelf library.

Usually my models only store data, meaning the files that contain them don’t have much code. The decision also depends on the tools you are using and who you are working with. I would fallback to the rule of separation of responsabilities and write a new class for the purpuse of serializing the model (which could and should also serialize similiar models). This way is universal in any language and can easily be understood by future you and colleages.

Related code should go together as much as possible, for maintainability.

If this results in too much code together, it’s time to think about other ways to structure the code so that each thing the user can do fits into as few files as possible, but not too many things the user can do share a file.

First option for each object. Unless things get bigger/tons of serializers/etc… then we move to the second-ish model.

To be honest, I usually just use whatever the framework has as best practices so that when new team members get on-boarded, theres less friction.

Storage concerns should be separate from the data model.

First option for small codebases. Second option when you know your codebase will grow large enough to break things apart into multiple packages.

The thing is, you typically need dependencies for de-/serialization. You only want those dependencies in the parts of the codebase that actually do the de-/serializing. And your model will likely be included in pretty much everything in your codebase, so the de-/serializing code should not be in there.
Well, unless your programming language of choice supports feature flags with which the de-/serializing code + dependencies can be excluded from compilation, then you can think about putting it into the model package behind a feature flag.

mainly java dev here:

if i only have few classes i want to serialize/deserilize i implement the logic for that in the class, if they need special logic for that, and implement the serilizable interface. writing objects to somewhere or reading them from somewhere belongs in a different class.

if i have a lot of classes or use a framework like spring i’ll employ whatever they offer for serilization and deserilization or more likely a databinding library like jackson.

other languages with classes or structs offer simmiliar options(pythons pickling and unpickling or the json package in their standardlib for example) so my approach would stay mostly the same.