Después de comprender el negocio, los productos, los clientes, los precios y el proceso de compra, podemos comenzar a traducir ese modelo comercial a la arquitectura de Drupal Commerce.
En esta etapa todavía no vamos a configurar una tienda paso a paso.
Primero necesitamos comprender las entidades fundamentales de Drupal Commerce, qué representa cada una y cómo se relacionan.
Los conceptos más importantes que estudiaremos son:
- Store
- Product Type
- Product
- Product Variation Type
- Product Variation
- Product Attribute
- Order Type
- Order
- Order Item Type
- Order Item
Comprender correctamente estas relaciones es fundamental para diseñar una arquitectura Commerce que pueda evolucionar sin convertirse en una colección difícil de mantener de tipos, campos y reglas especiales.
1. La arquitectura general
Podemos comenzar con una visión simplificada:
Store
│
├── Product
│ │
│ └── Product Variation
│ │
│ └── Purchasable Entity
│
└── Order
│
└── Order Item
│
└── referencia a Product VariationLa idea fundamental es que el Product representa normalmente el producto que mostramos y describimos al usuario, mientras que la Product Variation representa aquello que realmente puede comprar.
Cuando una variación se añade al carrito, Drupal Commerce crea un Order Item.
Ese Order Item termina formando parte de un Order.
Esta distinción entre producto, variación y línea de pedido es una de las ideas más importantes que debemos dominar.
2. Store: el contexto comercial
Una Store representa una tienda dentro de Drupal Commerce.
No debemos interpretar necesariamente una Store como una tienda física.
Una Store establece parte del contexto comercial dentro del cual se venden los productos y se crean los pedidos.
Podríamos tener una arquitectura sencilla:
Store
└── My Online ShopPero también pueden existir varias stores:
Drupal Commerce
│
├── Store Germany
├── Store Switzerland
└── Store AustriaLa necesidad de varias Stores debería surgir de los requisitos del negocio, no simplemente del hecho de tener varios países o idiomas.
Debemos preguntarnos:
- ¿Representan realmente operaciones comerciales distintas?
- ¿Utilizan monedas diferentes?
- ¿Tienen procesos comerciales distintos?
- ¿Gestionan pedidos independientemente?
- ¿Tienen catálogos diferentes?
Un Product puede estar asociado a una o varias Stores, mientras que un Order pertenece a una única Store.
Esto significa que el contexto de la Store forma parte importante del proceso de compra.
3. Store Type
Al igual que Drupal permite crear diferentes Content Types, Drupal Commerce permite definir diferentes Store Types.
El Store Type define la estructura de una determinada clase de Store.
Por ejemplo:
Store Type: Online Store
Fields:
├── Name
├── Email
├── Address
└── Custom fieldsEn muchos proyectos será suficiente disponer de un único Store Type.
Crear varios Store Types solamente tiene sentido cuando diferentes tipos de tienda necesitan estructuras o comportamientos diferentes.
4. Product Type: la estructura del producto
El Product Type define la estructura de una familia de productos.
Es conceptualmente parecido a un Content Type de Drupal.
Por ejemplo, una tienda podría tener:
Product Types
├── Book
├── T-Shirt
├── Laptop
└── Software LicenseCada Product Type puede tener diferentes campos.
Por ejemplo:
Product Type: Book
Fields:
├── Description
├── Author
├── Publisher
├── Cover image
├── ISBN information
└── CategoryMientras que:
Product Type: Laptop
Fields:
├── Description
├── Manufacturer
├── Technical specifications
├── Documentation
└── Product familyUna pregunta importante es:
¿Cuándo necesitamos crear diferentes Product Types?
La respuesta no debería ser simplemente:
Cuando los productos pertenecen a categorías diferentes.
Las categorías pueden modelarse perfectamente mediante taxonomías.
Normalmente necesitaremos Product Types diferentes cuando los productos tengan:
- Estructuras de campos diferentes
- Variaciones diferentes
- Procesos de compra diferentes
- Necesidades administrativas diferentes
- Comportamientos comerciales diferentes
5. Product: el producto que presentamos
El Product representa normalmente el concepto comercial que mostramos al usuario.
Por ejemplo:
Product Type
│
└── Laptop
Product
│
└── ThinkPad X1 CarbonEl Product puede contener información como:
- Nombre comercial
- Descripción
- Marca
- Imágenes generales
- Documentación
- Categorías
- Contenido SEO
Pero hay una característica esencial:
el Product no es normalmente la entidad que se añade al carrito.
Lo que el cliente compra es una Product Variation.
6. Product Variation: la unidad realmente comprable
La Product Variation representa la versión específica del producto que puede comprarse.
Supongamos que vendemos una camiseta:
Product
Drupal T-Shirt
Variations
├── Red / Small
├── Red / Medium
├── Red / Large
├── Blue / Small
├── Blue / Medium
└── Blue / LargePara el cliente existe conceptualmente una camiseta.
Pero comercialmente existen varias unidades diferentes.
Cada variación puede tener:
- SKU
- Precio
- Estado
- Atributos
- Campos personalizados
Por eso podemos resumirlo así:
Product
= lo que presentamos
Product Variation
= lo que vendemosEsta separación permite que diferentes versiones de un mismo producto puedan tener precios, identificadores o características comerciales diferentes.
7. Incluso un producto simple necesita una Variation
Una idea que inicialmente puede parecer extraña es que incluso un producto que no tiene diferentes colores, tamaños o configuraciones necesita una Product Variation.
Por ejemplo:
Product
"Drupal Commerce Handbook"
└── Variation
SKU: BOOK-001
Price: 29.90 EUREl producto solamente tiene una variación, pero seguimos manteniendo la separación entre:
Información del producto
↓
Product
Información comercial comprable
↓
Product VariationDrupal Commerce permite configurar un Product Type para trabajar cómodamente con una única variación cuando el modelo comercial lo requiere.
8. Product Variation Type
Así como un Product pertenece a un Product Type, una Product Variation pertenece a un Product Variation Type.
Podemos visualizarlo así:
Product Type
Laptop
│
└── Product
Laptop Pro 14
│
└── Product Variation Type
Laptop Variation
│
├── 16 GB / 512 GB
├── 16 GB / 1 TB
└── 32 GB / 1 TBEl Product Variation Type define la estructura de las variaciones.
Por ejemplo:
Variation Type: Laptop Variation
Fields / properties:
├── SKU
├── Price
├── RAM
├── Storage
├── Color
└── WeightTambién determina qué Order Item Type se utilizará cuando una variación sea añadida a un pedido.
Esta relación será especialmente importante más adelante.
9. Product Attributes
Los Product Attributes permiten representar características conocidas previamente que diferencian unas variaciones de otras.
Ejemplos típicos:
Color
├── Red
├── Blue
└── Green
Size
├── S
├── M
├── L
└── XLPodemos utilizarlos para generar combinaciones:
Product
T-Shirt
Attributes:
Color × Size
Variations:
├── Red / S
├── Red / M
├── Red / L
├── Blue / S
├── Blue / M
└── Blue / LLos Product Attributes son especialmente apropiados cuando conocemos de antemano todos los posibles valores.
10. Attribute no significa cualquier característica del producto
Este punto merece especial atención.
No todo campo descriptivo debería convertirse en un Product Attribute.
Por ejemplo:
Producto: Laptop
Manufacturer: Lenovo
Processor family: Intel Core
Documentation: PDF
Description: TextEstos pueden ser simplemente campos informativos.
Mientras que:
RAM
├── 16 GB
└── 32 GB
Storage
├── 512 GB
└── 1 TBpodrían ser atributos si el comprador utiliza esos valores para seleccionar qué variación desea comprar.
Por tanto debemos distinguir:
Información descriptiva
↓
Fields
Clasificación
↓
Taxonomy
Selección entre variaciones
↓
Product AttributesNo se trata de una regla absoluta, pero es una excelente forma de comenzar el modelado.
11. Variations frente a personalización
Otro concepto importante es que no toda opción seleccionada por el cliente debe crear una Product Variation.
Supongamos que vendemos una taza personalizada.
Product
Coffee Mug
Variation
White Mug
SKU: MUG-WHITE
Price: 12 EURDurante la compra pedimos:
Texto personalizado:
"Daniel"No necesitamos crear previamente:
Mug - Daniel
Mug - Maria
Mug - John
...El texto introducido por el comprador no identifica una variación del inventario.
Es una personalización específica de esa compra.
Podemos pensar conceptualmente:
Característica conocida previamente
y comercialmente diferenciable
↓
Product Variation / Attribute
Información específica de esta compra
↓
Order ItemEsta diferencia es extremadamente importante para productos configurables o personalizados.
12. Purchasable Entity: el concepto detrás de una Variation
Drupal Commerce introduce una abstracción todavía más interesante: la Purchasable Entity.
Una Product Variation es la implementación habitual de una entidad comprable, pero conceptualmente Commerce no está limitado exclusivamente a Product Variations.
Una entidad comprable necesita proporcionar información comercial básica como:
- Store
- Title
- Price
- Order Item Type
Por eso podemos visualizar la arquitectura así:
Purchasable Entity
▲
│
Product VariationPara la mayoría de proyectos utilizaremos Product Variations.
Sin embargo, comprender esta abstracción permite entender por qué Drupal Commerce puede adaptarse a modelos comerciales más complejos mediante desarrollo personalizado.
13. Qué ocurre cuando hacemos Add to Cart
Este es uno de los procesos que mejor explica la arquitectura de Commerce.
El usuario observa:
Product
Drupal T-Shirt
Color: Blue
Size: Medium
[ Add to cart ]Conceptualmente Commerce realiza algo parecido a:
Product
↓
Seleccionar Product Variation
↓
Blue / Medium
↓
Crear Order Item
↓
Añadirlo al Order / CartEsto nos conduce a la segunda mitad de la arquitectura: Orders y Order Items.
14. Order: el pedido
Un Order representa una transacción comercial que agrupa aquello que el cliente está comprando.
Un carrito es, conceptualmente, un Order que todavía se encuentra en una fase inicial de su ciclo de vida.
Podemos pensar:
Customer
↓
Cart
↓
Checkout
↓
Order placed
↓
Processing
↓
CompletedEl mismo Order evoluciona a través del workflow correspondiente.
El Order almacena información relacionada con la compra global, como:
- Cliente
- Store
- Estado
- Order Items
- Totales
- Información de facturación
- Ajustes
- Información adicional del pedido
15. Order Item: la línea del pedido
Un Order Item representa una línea dentro de un Order.
Por ejemplo:
Order #1001
├── T-Shirt Blue / M
│ Quantity: 2
│ Unit price: 20 EUR
│ Total: 40 EUR
│
└── Cap Black
Quantity: 1
Unit price: 15 EUR
Total: 15 EURCada una de esas líneas es un Order Item.
Un Order Item contiene, entre otras cosas:
- Referencia a la entidad comprada
- Cantidad
- Precio unitario
- Precio total
Por defecto, la entidad comprada será normalmente una Product Variation.
La relación fundamental es:
Order
│
└── Order Item
│
└── Purchased Entity
│
└── Product Variation16. Por qué existe el Order Item
Podríamos preguntarnos por qué el Order no referencia simplemente directamente a las Product Variations.
La respuesta es que una compra necesita almacenar información propia de ese momento.
Por ejemplo:
Product Variation
SKU: SHIRT-BLUE-M
Current price: 25 EURPero un pedido realizado anteriormente podría contener:
Order Item
SKU purchased: SHIRT-BLUE-M
Quantity: 2
Unit price at purchase: 20 EUR
Custom text: "Company Event 2026"El Order Item representa la línea comercial dentro de la transacción.
Esto permite almacenar información específica de esa compra sin modificar la Product Variation.
17. Order Item Type
Al igual que tenemos Product Types y Variation Types, también podemos tener diferentes Order Item Types.
Un Order Item Type define qué información necesita una determinada línea de pedido.
Por ejemplo:
Order Item Type
Physical Product
Fields:
├── Purchased entity
├── Quantity
├── Unit price
└── Total priceMientras que un producto personalizado podría necesitar:
Order Item Type
Custom Product
Fields:
├── Purchased entity
├── Quantity
├── Unit price
├── Custom text
└── Uploaded logoEsto es especialmente poderoso porque permite almacenar información que pertenece a la compra concreta y no al producto global.
18. La relación entre Variation Type y Order Item Type
Una Product Variation Type está asociada a un Order Item Type.
Esto significa que Commerce sabe qué tipo de línea debe crear cuando una determinada variación se añade al carrito.
Product Variation Type
T-Shirt Variation
│
│ uses
▼
Order Item Type
Physical ProductCuando compramos:
T-Shirt / Blue / Medium
↓
Product Variation
↓
Order Item Type
↓
Order Item
↓
OrderEsta relación es una de las piezas centrales de la arquitectura de Commerce.
19. Order Type
Los Orders también pertenecen a un Order Type.
Esto permite tener diferentes clases de pedido.
Por ejemplo:
Order Types
├── Physical products
└── Digital productsPodríamos necesitar que cada uno tenga procesos diferentes.
Un pedido físico podría seguir:
Draft
↓
Placed
↓
Paid
↓
Fulfillment
↓
CompletedMientras que un producto digital podría necesitar un proceso más sencillo:
Draft
↓
Placed
↓
Paid
↓
CompletedLos diferentes Order Types pueden utilizar diferentes workflows y diferentes Checkout Flows.
Esto permite adaptar Commerce a procesos comerciales distintos sin introducir continuamente condiciones especiales dentro de un único flujo.
20. El carrito también es un Order
Otra idea fundamental es comprender que el carrito no es una estructura completamente independiente.
Conceptualmente:
Empty
↓
Add product
↓
Order created as Cart
↓
Add Order Items
↓
Checkout
↓
Order placedMientras el cliente continúa comprando, el Order permanece en estado de borrador y funciona como carrito.
El checkout posteriormente transforma esa intención de compra en un pedido formal dentro de su workflow.
Esta arquitectura evita tener que convertir una estructura de carrito completamente diferente en un pedido al terminar el checkout.
21. Una visión completa del modelo
Ahora podemos combinar los conceptos estudiados.
STORE
│
│
├─────────────────────────────────┐
│ │
▼ ▼
PRODUCT ORDER
│ │
│ │
▼ ▼
PRODUCT VARIATION ORDER ITEM
│ │
│ │
└──────── Purchasable ────────────┘
EntityIncluyendo los tipos de configuración:
Store Type
│
└── Store
Product Type
│
└── Product
│
└── Product Variation
▲
│
Product Variation Type
│
└── Attributes
Order Type
│
└── Order
│
└── Order Item
▲
│
Order Item TypeY la relación comercial principal:
Product
↓
Variation
↓
Add to cart
↓
Order Item
↓
Cart / Order
↓
Checkout
↓
Placed Order22. ¿Dónde debería vivir cada dato?
Una de las decisiones más importantes durante la arquitectura consiste en determinar dónde almacenar cada campo.
Podemos utilizar esta guía conceptual:
Product
Información común a todas las variantes.
Title
Description
Brand
Category
Documentation
General mediaProduct Variation
Información que cambia entre unidades comprables.
SKU
Price
Color
Size
Weight
Specific imageOrder Item
Información específica de esta compra.
Quantity
Unit price
Personalization
Gift message
Configuration selected by customerOrder
Información correspondiente a la transacción completa.
Customer
Billing information
Store
Order status
Payment context
Order-level informationUna pregunta muy útil durante el diseño es:
¿Este dato describe el producto, la unidad que se vende, la línea comprada o la transacción completa?
La respuesta suele indicarnos dónde debería vivir.
23. Ejemplo: una tienda de camisetas
Podemos aplicar todo el modelo a un ejemplo sencillo.
Store
Proton Clothing
Product Type
T-Shirt
Product
Drupal Developer T-Shirt
Product Variation Type
T-Shirt Variation
Attributes
├── Color
└── Size
Variations
├── TS-RED-S
├── TS-RED-M
├── TS-BLUE-S
└── TS-BLUE-M
Order Item Type
Physical Product
Order
#1001
Order Items
├── TS-RED-M × 2
└── TS-BLUE-S × 1Podemos seguir visualmente una compra:
Drupal Developer T-Shirt
↓
Color: Red
Size: Medium
↓
Variation TS-RED-M
↓
Add to Cart
↓
Order Item
Quantity: 2
↓
Order / Cart
↓
Checkout
↓
Order #1001Este pequeño ejemplo contiene prácticamente toda la arquitectura básica sobre la que construiremos el resto de Commerce.
24. No crear tipos innecesariamente
Drupal Commerce ofrece mucha flexibilidad, pero esa flexibilidad puede llevarnos a sobrediseñar el sistema.
No necesitamos crear automáticamente:
- Un Product Type por cada categoría
- Un Variation Type por cada producto
- Un Order Item Type por cada Product Type
- Un Order Type por cada familia de productos
- Una Store por cada idioma
Debemos crear una nueva estructura cuando exista una diferencia real de datos o comportamiento.
Por ejemplo:
¿Los productos tienen diferente estructura?
↓
Tal vez Product Types diferentes.
¿Las unidades vendibles tienen diferente estructura?
↓
Tal vez Variation Types diferentes.
¿Las líneas de pedido necesitan datos distintos?
↓
Tal vez Order Item Types diferentes.
¿Los pedidos siguen procesos diferentes?
↓
Tal vez Order Types diferentes.Esta forma de pensar ayuda a mantener la arquitectura sencilla.
25. Una regla práctica para modelar Commerce
Podemos utilizar cuatro preguntas durante el diseño:
1. ¿Qué presentamos?
↓
Product
2. ¿Qué compramos?
↓
Product Variation
3. ¿Qué estamos comprando en esta transacción?
↓
Order Item
4. ¿Cuál es la transacción completa?
↓
OrderSi comprendemos claramente estas cuatro respuestas, gran parte del modelo de Drupal Commerce comienza a resultar natural.
Conclusión
La arquitectura básica de Drupal Commerce se basa en separar claramente diferentes responsabilidades.
Store
= contexto comercial
Product
= representación del producto
Product Variation
= unidad comprable
Product Attribute
= característica utilizada para seleccionar variaciones
Order Item
= línea concreta de una compra
Order
= transacción comercial completaAlrededor de estas entidades tenemos sus respectivos tipos:
Store Type
Product Type
Product Variation Type
Order Item Type
Order TypeEstos tipos nos permiten añadir campos, configurar comportamientos y adaptar Commerce al dominio específico del negocio.
Por eso no deberíamos comenzar un proyecto creando tipos arbitrariamente.
Primero modelamos el negocio y posteriormente utilizamos las entidades de Commerce para representarlo.
En el siguiente artículo podremos dar el siguiente paso: diseñar el catálogo de productos, profundizando en Product Types, Product Variation Types, Attributes, campos y taxonomías, y aprendiendo a decidir correctamente qué información debe almacenarse en cada nivel.