IMO, the pattern is that model is a single source of TRUTH. A fullName is not truth, it’s an opinion on how two pieces of truth should be combined. It’s entirely possible that this distinction is trivial to your application (or Discourse), or that “fullName” is a well-enough understood computation that you have nothing to gain but performance by storing it in your model. Bottom-line, if you do this, absolutely no one on your team is going to call you a dummy, and you’re probably not going to lose a job if you answer this on an interview question.
Your original question was about patterns, and I would rules-lawyer about this absolutely being an anti-pattern. I want whatever is controlling my data to only care about what the lowest level of truth is. What fullName, or mailingAddress, or combinedSocial might be in my application could be completely different in someone else’s, or in mine a month from now, or in this page when I change how it works. This pattern allows you to have one version of fullName on one route, and a different one on another route. This is super-desirable when those routes are developed by different people who don’t talk to each other as much as they should.
Really, the entire philosophy of data design is based around some truly conspiratorial worries- “What if three middle names becomes the standard?” or “What if global addresses become single integers?” Good application design is impervious to these changes because of patterns.
In the brutally honest real-world, no one is going to use your application except you and maybe your client. Storing a computation in the model (why not the database!) is faster. So is denormalizing. Patterns will protect you from when the entire use-case shifts. It’s a 100% judgement call whether the pros outweigh the cons on that for you.
The pattern is to keep any opinionated, domain-specific data implementation away from persistence as much as possible. For me, that would include ember models.