When a system must handle changing records, representing each entity as a generic data structure avoids tying its data to a particular domain class. A record becomes a heterogeneous string map, while collections use lists or indexed maps. Code depends on the field names it needs, not on the complete representation, creating a weaker dependency between data and the functions that manipulate it. section 3.0 section 3.6
The approach trades some compile-time safety for flexibility:
- Represent records with string-keyed maps whose values may be primitives, lists, or nested indexes. section 3.6
- Access nested values through information paths and manipulate them with generic functions. section 3.0
- Add, remove, rename, merge, filter, group, or select fields without changing a class hierarchy. section 3.6 section 10.5
- Accept weaker field-access safety in exchange for late binding, genericity, visualization, and easier adaptation to changing requirements. section 3.6
A web-service request and response
A search endpoint can parse a JSON request such as {"title":"habit","fields":["title","weight","number_of_pages"]} into a map. Business logic selects fields by name, combines database data with an external API result, and serializes the resulting map for the client. Nesting avoids field conflicts but produces a non-flat result; merging produces a flat map but requires a conflict policy. section 11.3 section 11.5
The same representation suits database results: relational rows become lists of maps, and generic functions can operate across different entities. It also lets inner web-service components communicate through data rather than importing one another’s class definitions, keeping components loosely coupled. section 10.0 section 11.2
Lodash functions introduced in this chapter
Use the Lodash reference to browse concrete operations for reading paths, merging maps, extracting values, filtering collections, and mapping elements. section 3.6
