An interesting challenge in Content Modeling for large projects is clarifying the boundary lines between content types. Discrete types are important, after all, for lots of reasons — but on many projects, they either multiply into unsustainability or bleed into each other.
e.g., An “article” about someone is an “interview” when it is explicitly formatted as questions and answers; a “profile” when it’s a quote-laden narrative. The two might call for different structural elements, visual treatments, and editorial workflows. Then, of course, reviews…
The question, though, is often: "Do we spin off many conceptual content types, each clearly serving a well-articulated need, or do we make them all “articles” and handle the unique elements as they come? It’s a tough call, with no objectively correct answer.
Something we’ve found helpful is borrowed from the Python programming language: “duck typing.” A software object can be considered a particular 'kind of thing" if it has all the properties that define that thing. If it looks like a duck and quacks like a duck, it’s a duck.
The idea is that you explicitly codify broad categories of content in particular content types, then provide tools for accomplishing the different concrete use cases for those broad types using explicit field-level properties, standardized markup, composition or embedding, etc.
“We have articles; Interviews are just articles with a series of questions and answers rather than a single textual narrative; Reviews are just articles that have product data and a rating;” and so on.
HOW you build out those different applications varies from CMS to CMS, from tech stack to tech stack, but the approach has helped us on quite a few occasions. (Even as far back as the redesign of The Toast, when they were facing this very challenge.)