# Customizer Platform
# Products Architecture and Configuration
# Overview
TIP
As a part of the Customizer implementation engagement, the Drive Commerce team will assist with defining and configuring the product model.
Rather than completely replacing all management aspects of customizable products, Customizer aims to augment existing e-commerce systems. Products continue to be configured in the host website e-commerce environment, holding information about availability, pricing, inventory levels, etc. Customizer backend in its turn is responsible for storing detailed information about the custom product architecture — defining how products are built, which components are customizable, and potential customization options.
Customizer flexible data model provides a way to configure a large variety of products. At the core, products are defined by following elements:
- Component options
- Component placements
- Product definitions
- Product versions
These elements define the product taxonomy and architecture, the basic building blocks from which any customizable product can be built. These building blocks are shared among all product instances and versions.
For example, the product model may include a list of available colors and their related part codes, such as a Pantone color that identifies a specific thread color. Typically color attributes such as identifiers, codes, names will not vary the meaning between different products (Blue is Blue everywhere), thus making it easier to maintain a single list as the source of truth for all colors.
# Component Options
Component option definitions and component options are the most basic product elements. Definitions are a way to create groups of related options and specify some common characteristics.
For example, an implementation of a customizable product may include option definitions for concepts like materials, colors, personalizable options, user-defined content, etc.
Component options in turn would describe specific instances of each of definitions: materials could be one of leather, metal, plastic; colors may be one of red, blue, green, etc; personalization options could include bold or italic font styles, Arial or Times font family, etc.
# Widgets
Component options typically describe product elements that have to be selected by consumers to create a final product. Most options would be displayed on the customization user experience, represented by buttons, sliders, toggles, file uploaders, etc. Customizer allows configuring presentation of each option using the custom attributes extensibility model.
# Component Types
Next level in the product architecture is component types. In many cases, component options need to group to form a valid component that could be used to build a product. For example, materials and colors may exist as separate options (Canvas, Mesh, Leather materials; Red, Blue, Brown colors), product parts require some valid combination of both — Red Canvas, Blue Mesh, Brown Leather. Component types define such relationships.
Some component types describing simple product elements can have a one-to-one correspondence to component option definitions, while complex product parts may consist of multiple definitions. For example, a product part may need to have a selection of a material and color to be valid.
# Component Placements
Placements are the primary building block of products. While component options and component types exist mostly as separate reusable Lego pieces, placements level is where product structure defined.
Placements serve as containers into which component options can be slotted to build a complete product. Each product must be composed of one or more placements.
# Products
Products finally tie together all previously discussed elements and complete the product architecture:
- Products combine available placements. For example, a shoe may have a customizable toe, sole, laces, heel placements.
- Products define allowed component options for each connected placements.
Products use style codes as their primary identifiers.
# Product Mixins
In many cases, product architecture can be rather simple, with products defining available placements, component options that are allowed in each placement, etc.
However, implementations may have unique requirements:
- Multiple distinct but similar products
- A product placement that is shared among multiple products
A mixin is a partial product configuration, defining all or some aspects of products. For example, a mixin can outline image views, or component placement associations, or some other configuration options.
Mixin typically cannot be viewed or configured by itself in the front-end experience. However, multiple mixins could be combined together to form a complete product. An implementation may define a number of mixins to reduce the complexity of product management and configuration.