Decoupling the physical storage of the model from its logical representation is a very important capability if you want any sort of agility down the road. The way we do this is fairly simple:
- Maintain a common domain model stored in a shared dll. This is a POCO type without any methods or mappers of its own. All it does is contain all the facts you might need. To encapsulate everything into a serializable structure, we place all top-level domain types as collections into an aggregate type simply called "Domain".
- Maintain mappers to/from the domain model in the locations most appropriate for these to live. These mappers could talk to SQL, memory, some noSQL garbo, the user's web UI, etc.
The advantages with this layer of separation almost universally outweigh the downsides unless you can convince your development team to build a more standardized single-process/monorepo product. In a simpler product, I would be more inclined to just directly interact with SQLite via anonymous types.
We have used ORMs like EF in the past, but these get in the way really badly and prevent you from building your logical model in precisely the way you want to.