Commerce Product Catalog Modeling Principles

A proper product catalog model underpins the success of any online commerce solution. The key ingredients for good modeling are:

  • simplicity. The catalog objects (items) must follow the precepts of good domain-driven design with bounded contexts. Each object should have a unique purpose and representation.
  • coupling. Loose couplings should be used whenever possible, so as to ensure that an object does not assume too many responsibilities. Tight couplings across objects should be used primarily when the conjoined objects are always referenced and used in conjunction with one another. This is an extension of the SOLID principles espoused by “Uncle” Bob Martin. An example of a loose coupling is a catalog reference id, such as how inventory items reference SKU and product items. An example of a hard coupling is a (foreign) repository item reference.
  • separation of concerns. Each object and its associated manager or tools class should be defined in such a way as to overlap in functionality and representation as little as possible with other managers and their respective objects.
  • localization. Data is injected and maintained in only those portions of the system needing to manage, enhance, and reference it.

The advantages provided by way of proper catalog model include:

  • optimal cacheability of the objects in heap, as close to the underlying classes referencing the objects as possible with elongated associated TTLs
  • lazy loading and lazy evaluation, so that only those portions of objects are retrieved and cached upon loading or reference that are in use
  • avoidance of brittle linkages, whereby updates to properties of objects have no cascading effects on other objects leading to defects
  • improved system scalability, where the number of instances (ATG page serving or Endeca MDEX)
  • improved request handling performance, where pages resolve in consumer browsers
  • faster indexing and content promotion into the search engine (Endeca)
  • more highly localized faceting control providing the ability to control the exact configuration of facets
  • less dependence upon category traversal for consumers attempting to find products of interest
  • reduced deployment time, both in sending merchandised data to commerce for product browse and sales and to Endeca for search
  • reduced housekeeping: pruning old versions of objects, running catalog maintenance services, etc.

These advantages lead to:

  • fewer defects
  • improved scalability and request handling performance
  • increased code production velocity, whereby development is able to produce new features more quickly
  • a nimbler implementation, where existing features can be enhanced more quickly and with increased surety
  • less operational overhead
  • better search refinement and faceted navigation of catalog assets
  • improved customer experience, getting customers to the products of interest more quickly and with increased relevance

So why are these things important?

Here are some of the symptoms that you might experience if you don’t abide by these principles.

Failure to optimize cacheability and exploitation of lazy loading will result in objects being pulled into cache unnecessarily, and kept in cache based on the referencing items which may have no connection to what is needed for these objects. This results in very poor memory utilization, excessive garbage collection, excessive paging in the operating system, etc. In essence, excessive strain on memory management and on the database(s) underpinning the repositories.

Excessive use of hard couplings may result in locking conflicts during deployments, unnecessary updates to parent or sibling items significantly enlarging the numbers of items needing to be deployed, items being retained in cache that are not actively being referenced or manipulated, etc. thereby degrading both deployment success and performance as well as the exacerbating the cacheability issues discussed.

Complex categories, and hard links result in referenced data being pulled into projects and deployed when the referring item is changed.  This results in much larger projects, more conflicts, and slower business processing times.

Hard couplings (references) will result in retrieving all referenced data during indexing and require that data to be parsed, resulting in slower extraction from the catalog and indexing, often to an extent that it does not meet business needs. They will also result in more versions of objects being created, resulting in a faster growing database which will either slow down the system for business users or require more purging and management.

All of the above will lead to a greater number of defects, reduced scalability and performance, and most complex operations which in turn will increase your total cost of ownership [TCO]. In essence, Oracle Commerce is an object oriented system so all modeling should adhere to good object-oriented modeling and design principles.

Add Your Comment