Promotions Refactor

[jmataya]

Overview

One of the hallmarks of our platform is the feature that we lovingly know as our Object Model. It is a flexible, versioned, and branch-able model for storing content. It's currently the data store for:

• Products
  • Product
  • SKU
  • Variant
  • VariantValue
• Images
  • Album
  • Image
• Taxonomies
  • Taxonomy
  • Taxon
• Discounts
  • Coupon
  • Promotion

Despite the power and flexibility of the model, it's clear that there are some problems that need to be solved. Those can be bucketed into two categories:

1. High cognitive overhead when using Object Model
2. Engineering enhancements to the Object Model
3. Incorrect usages of Object Model

Goals

The purpose of this document is to begin solving the problem of lessening the cognitive overhead needed to understand our system by tackling the most unnecessary usage of Object Model: promotions.

Non-Goals

While there are a number of engineering improvements needed to correctly tackle problems like versioning and branching across the catalog, solving them is outside the scope of this document.

The long-term solutions for using Object Model, as it relates to Products and Taxonomies include:

• Strengthening abstractions so that application code does not use lower-level details of the model, such as ObjectForm and ObjectShadow
• Moving Product (and related entities) and Taxonomy (and related entities) from Phoenix and into the service that will form the foundation of our CMS.

More on this in future documents!

Refactoring Promotions

Remove Object Model When Not Needed

Object Model is useful in places where we want to have a structure that is very flexible, consistently versioned, and predominantly about content. It has been overused, most particularly in Discounts.

So, one of the first steps to improving the cognitive model of Object Model is to stop using it in places where it's not well equipped to solve a problem.

Requirements

1. Goals

   Migrate discount entities to a standard relational model

   Discounts, Coupons, and Promotions should abandon the flexible Object Model in favor of a more rigid system. These models are fundamentally structured entities that don't need the flexibility afforded by Object Model.

   When we migrate, ensure the following conditions are met:

   • Keep all standard fields in the relational model (e.g. name)
   • Preserve ability to set active/inactive status
   • Preserve ability to add tags

   Update Admin UI To Handle Non-Object JSON

   One of the artifacts of

2. Non-Goals

   • Context-based promotions and coupons
   • Versioned promotions and coupons
   • Custom fields on promotions and coupons

Next Steps

• [ ] Define promotions table structure
• [ ] Define coupons table structure
• [ ] Define discounts table structure

[annappropriate]

https://docs.google.com/document/d/1xfJJzPBprK_eHCzg-SFZXoRTrAszbk2o9B9QydZl2w4/edit#heading=h.qc2iqbioajdj