Closeness of mapping measures how directly code mirrors the structure and concepts of the problem. Code feels closer when its names, cases, and transformations match the domain instead of forcing awkward detours through incidental language machinery. section 5.1
A useful test is whether the code makes the underlying idea visible without reconstruction. Direct domain modeling can reduce cognitive complexity, boilerplate, and hidden case-handling work, while also making invalid or missing cases easier to detect. section 5.1.5 section 5.3
Modeling book formats directly
Represent a Book as one of three explicit variants—DigitalBook, PocketBook, or HardcoverBook—and select its promotional message by pattern matching. The digital variant returns its download link; the physical variants return format-specific messages. The cases correspond directly to the domain, without an enum, temporary variable, or cast. section 5.1.5
Listing 5.5 Selecting a promotional message with Haskell pattern matching
data Book = DigitalBook String String | PocketBook String | HardcoverBook String deriving (Show, Eq) getPromotionalMessage :: Book -> String getPromotionalMessage (DigitalBook _ downloadLink) = downloadLink getPromotionalMessage (PocketBook _) = "Same book, smaller format!" getPromotionalMessage (HardcoverBook _) = "Old-fashioned book..."
Inspect the complete Haskell definition and promotional-message function to see the domain variants mapped directly to behavior. section 5.1.5
Closeness is not a license to choose the shortest construct blindly. Prefer the form that keeps the problem visible while balancing readability, conciseness, safety, and the reader’s background knowledge. section 5.3
