1. 13
  1. 11

    I would have expected something like replacing a person with a placeholder when removing it, but erecting a tombstone when deceasing a person was so much better.

    The first version is clear and self-explanatory and unambiguous. The second could mean anything. Worse, it has a literal meaning that is also a reasonable thing for a piece of code to do, but has no relation to the actual intended purpose: when I looked at the code snippet preceding that quote, my mind jumped to, “Oh, this is handling memorializing an account for a person who has passed away.”

    1. 2

      Agreed. That part confused me for a while because I thought the same.

      What the author calls “bold code” is just the domain driven version of “clever code” to me. I don’t like clever code outside of hobby projects and competitions.

    2. 3

      To me it’s seems to be the opposite of Domain-Driven Design: the language used in the code is different from the language used in the domain (supposedly and seeing the reaction of the author). As koreth said, the tombstone version is ambiguous (“this software can handle deceased persons”). This looks more like an analogy than DDD.

      I prefer the Petitioner example which is a good showcase of having to convey a rich concept with a single word and that the first coming words we think about are really common especially in source code (“request”, “authorization”, “approval”). Naming thing is hard. It’s even harder when you work in a domain where there is a jargon you have to understand, to apply in the code and that you have to translate because your native language is different than the language used in the code. For example I speak with my team in French, trying to use same jargon than the people in the field but in the code everything must be in English, it’s really hard to find the right translation especially since I’m not a native English speaker.

      1. 1

        This is the sort of cuteness in naming I would expect from a beginner, not a well-established engineering team.

        The whole point of DDD is that you’re using unambiguous and real-world language to describe the concepts in code. This is not that.