Content Modelling - Step 3 - Identify key classes

Define the key classes within the model:

  • Business Profile

  • Location

  • State

  • Product/Service

  • Category

These are fleshed out with attributes in the functional specification but for preliminary work it should be enough just to identify them. We aren't trying to identify EVERY object in the system; that will come later. There will be key objects that provide the core of the system. We can add other objects at a later date that may have nothing to do with the model and are just for additional content, more to do with sales and marketing than the business process we are automating.

When defining these objects it's important to use the same language as the client. For example, if the client groups products by "variety" then use the term variety rather than product group. If you try to use your own terms then there's the possibility for confusion at a later date when you're talking about details to do with product groups and the client has forgotten that you mean "variety" and doesn't realize that a permission or relationship is wrong because they don't fully understand what we mean by a product group.

Once again, if we are dealing with a known business system, chances are the objects we are talking about will already have known terms. If we are dealing with a new system that is being created as a part of the solution being built, then it's a bit more tricky. Names are very important—although Shakespeare wrote "What's in a name? That which we call a rose, by any other name would smell as sweet;" in a content model, the name given to the object is important. It has intrinsic meaning and if you use an arbitrary or misleading name, it can create confusion not only for the client but developers also, and ultimately the user. When choosing names, there are a couple of simple rules: be clear, keep them short.

Clarity comes from the name reflecting the nature of the object e.g., customer, member, supplier, product, property, etc. Name length is important when it comes to programming and displays. Long names take longer to type, a simple thing, but you don't want to have to be typing "science_ideas_and_concepts_worksheet" each time you want to access that particular object. Even though a CMS may allow the identifier to be different from the name, it's a good idea to make them the same to avoid confusion.

Long names are also a pain when it comes to displaying the class. Often, the class name will be displayed as a part of the navigation, e.g. in a breadcrumb or as an identifier in a search result. This is where long names can cause problems. Once you've set the name, it's understood by the client and developers, templates have been coded and content entered, changing that name will be a lot of work. This is somewhat pendantic but names have instrinsic meanings. Great care needs to be taken in selecting names. What seems like a simple thing upfront can have ramifications down the track if care is not taken.