strangemonad
commented
6 years ago This has some parallels with using the modeled object vs type aliasing to an equivalent type in the target language #5
Open strangemonad opened 6 years ago
strangemonad
commented
6 years ago This has some parallels with using the modeled object vs type aliasing to an equivalent type in the target language #5
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