If you're a Drupal developer who designs information architecture (IA) for your organization and/or clients, then hopefully by now you're thinking in terms of entities, bundles, and fields, not limiting your thinking to only content types.
This article isn't going to dive into a lesson explaining what entities, bundles, and fields are as there is plenty of great documentation about that.
Back in the Drupal 7 and earlier days, it was common to look at an organization's data and map it almost exclusively to only content types (maybe a few vocabularies as well). With Drupal 8's and 9's Entity API now fully mature, it's time to check yourself and make sure you take into account all of the amazing entity types that are available in both Drupal core and well-used and -maintained contributed modules.
With that in mind, the next time you are designing the information architecture for a Drupal site, be sure to consider the following entity types.
- User (core) - one of the original core entity types - still fieldable, but still not bundleable. For that, use…
- Profile (contrib) - this useful module allows you to create various "profile types" that can be associated with each user. Examples include "author" profiles, "contributor" profiles, and "VIP" profile.
- Vocabulary (core) - another original core entity type (if it ain't broke…)
- Content type (core) - the original and still the best, but often overused.
- Block type (core) - new in Drupal 8, replaces Drupal 7 modules like Bean and Boxes that provided custom, fieldable block types. Block types are great for lightweight, reusable content that doesn't need a dedicated path on your site. Block types are great for supporting content.
- Media (core) - starting with Drupal 8.4, media entities are now part of Drupal core. These are incredibly useful fieldable entity types if your site includes things like PDF files or videos (both locally-hosted and remote). For example, no longer do you need to create a "Document" content type to upload documents that are related to various other entities on your site.
- Paragraphs (contrib) - this popular and well-maintained contributed module allows authors to mix and match various "paragraph types" (fieldable entities) in an effort to create custom layouts of (often) nodes. In this author's opinion, Paragraphs module is best used as a WYSIWYG replacement for the body field, and not as an overall page layout tool. The power of Paragraphs module lies in the fact that a site designer can create and style various paragraph types that site authors can then utilize to provide creative layouts for their content.
- Drupal Commerce (contrib) - another extremely well-maintained contributed module provides several entity types related to ecommerce, including product types, orders, and more.
- Comment types (core) - new to Drupal 8, allows your site to have different types of comments. This can be very useful, but in our experience, not used all that often.
- Contact forms (core) - new to Drupal 8 and similar to the Drupal 7 Entityform module. The idea was to create a Webform-like entity type, but in our experience, Webform still continues to be a better solution in the vast majority of use cases.
While this list isn't exhaustive, we believe these are the ones that most Drupal developers will most likely utilize.
Drupal Career Online, our 12-week, twice-a-week, online Drupal training program teaches not only most of all of these entity types, but also how to figure out when to use each one. We also focus on how to work with various project stakeholders in validating the IA design early in the development process in order to keep costs and future changes to a minimum.
For Paragraphs, I would add that they are powerful in modelling an embedded collection of field values in the content data model. So regardless of how they may (or may not!) be displayed, I recommend using them for their flexibility for a data structure. This is how field collections often got used in Drupal 7 too. It's for those times when you want to have multiple pairs of fields together on a 'parent' entity - or more than pairs.
That said, they can't exist independently and aren't (usually) re-usable, so sometimes a multivalue entity reference to a different 'embedded' entity (perhaps using an inline entity form widget) from a more suitable 'host' entity can be more appropriate.
Either way, the real point is that you may want to keep your ideal data model/structure separate to your ideal display/layout system(s). Modules like https://www.drupal.org/project/layout_paragraphs can help with this, allowing you to independently perfect your data model, and then you can separately add your approach to displaying the content afterwards.
As for comments ... I've found them useful for any kind of user 'response' to another entity. For example, an RSVP to an event or a 'like' action. Using different fields for different bundles (sometimes even on the same target entity!) allows stripping them back for the user's response to mean something very different to just commenting with some text.