Explore refs vs object graphs

[strangemonad]

Domain models tend to gravitate towards object graphs but that's shitty for lots of practical reasons. (NOTE: none of this deals with cardinality > 1 e.g. lists, sets, maps)

1. hard to optimize DB access patterns, often wasteful (we don't need the whole graph)
2. hard to control network wire size for clients that just want a view of things
3. bad for memory footprint (heap or stack) and GC patterns of the process itself

Entity boundaries are sometimes fuzzy and often application specific. When modeling at a high level you sometimes care that the model is directly contained (i.e. the hierarchy's solid lines). Sometimes you care specifically that it's a reference to another entity. Sometimes you're happy with either a ref to the entity or that entity itself but you do care that access times are deterministic and controllable (ie when will the data be faulted in am I in the same DB transaction so that I'm seeing the same view of data, can I memoize the result, etc). Determining this starts broaching into linear types / linear logic

[strangemonad]

This has some parallels with using the modeled object vs type aliasing to an equivalent type in the target language #5