Couple design options I'm wrestling at and trying to come up with a third because both of these feel a little off

Putting together a hierarchical domain model of dumb objects to exist as an in-memory information store. Easy POCOs to put together and such, but because of it's purpose, constant updates will be coming in as well as constant reads from it etc.

The classical approach would be just implement a repo over top of it, single class that has gets/updates for all the different types of entities throughout the model

I'm going back and forth with that though, because a repo is a fair bit of maintenance as a single piece over time, though it gives a nice loose coupling through the system in a single place

Alternatively I'm thinking about making the update messages coming in have a function that knows how to apply it's particular update with protection via internals so other classes couldn't write to the model; then expose the model as a live readonly graph. This makes writing reads against the model a breeze, as well as diminishing maintenance and getting clean segregation of read vs update which is always good to have go through different channels

this way the only repo-maintenance could be the update methods on the update messages

but it tightly couples the reading code to the particular domain model implementation, short of putting interfaces over each entity which is somewhat silly, the underlying implementation won't be replaceable without changing everywhere that reads from it

I'm leaning towards option number two because it seems like less maintenance over time with those update methods singly boxed up, and not having to write repo methods for every read, and largely because given the purpose of this model - the idea that the underlying implementation will ever need to be changed is pretty far fetched