3 ms·

- Not all project-related terms map to types - The "types that define those entities" (that do map) can be scaterred across multiple source code files (so this

- Not all project-related terms map to types - The "types that define those entities" (that do map) can be scaterred across multiple source code files (so this would also scatter the definitions) - The code is not where people look for reference, even more so for non-coders that still need to refer to the same things (e.g. UX, sales) - The definitions that do map to types, could still be reusable in multiple code projects. Putting them in the code means you need to repeat them, make sure they're consistent, and sync them across codebases when some definition is changed/improved. -

valenterry 3y ago
The last 3 points make a lot of sense. The first one however I don't understand. Do you mind to give one or two concrete examples of that?
- coldtea 3y ago
  >The first one however I don't understand. Do you mind to give one or two concrete examples of that? Not everything about a project maps to a type. The team might have to handle the issue (and have a way to talk about the problem) of back-pressure for example. Doesn't mean there's a back-pressure type in the server code, or a "back-pressure-handler" class or something like that. And that's still a term referring to a core tech aspect. There are terms related to projects that teams need to agree on that are appplicable to the sales or marketing or user documentation of the software, and not classes.