# Modelar el catálogo en Drupal Commerce: Products, Variations, Attributes, Fields y Taxonomies Enviado por [danieluxury](/es/user/1 "Ver perfil del usuario.") el Vie, 25 Sep 2026 - 11:39 Una de las decisiones más importantes en un proyecto Drupal Commerce es cómo representar correctamente el catálogo. Antes de crear Product Types, campos o taxonomías debemos responder una pregunta fundamental: > ¿Cómo está estructurada realmente la información comercial que queremos vender? Un catálogo bien modelado facilita la administración, los filtros, la búsqueda, el mantenimiento, las integraciones y futuras ampliaciones del sitio. Un catálogo mal modelado puede funcionar inicialmente, pero suele terminar acumulando campos duplicados, Product Types innecesarios, variaciones difíciles de mantener y reglas especiales para resolver problemas que en realidad nacieron en el modelo de datos. En este artículo aprenderemos a decidir cuándo utilizar: - Product Type - Product - Product Variation Type - Product Variation - Product Attribute - Field - Taxonomy El objetivo no es memorizar configuraciones, sino desarrollar un criterio que podamos reutilizar en diferentes proyectos Commerce. --- ## 1. Empezar por el catálogo real No deberíamos comenzar preguntándonos: > ¿Cuántos Product Types debemos crear? Primero necesitamos observar el catálogo del cliente. Supongamos que una empresa vende: ```plaintext Catálogo ├── Camisetas ├── Sudaderas ├── Zapatos ├── Mochilas └── Accesorios ``` Sería tentador crear inmediatamente: ```plaintext Product Types ├── Camiseta ├── Sudadera ├── Zapato ├── Mochila └── Accesorio ``` Pero esta decisión podría ser incorrecta. Es posible que todos esos productos tengan exactamente la misma estructura: ```plaintext Title Description Brand Category Images Variations ``` En ese caso podríamos utilizar un único Product Type: ```plaintext Product Type Product ``` y representar las categorías mediante Taxonomy: ```plaintext Product Category ├── Clothing │ ├── T-Shirts │ └── Sweatshirts │ ├── Shoes ├── Backpacks └── Accessories ``` La categoría comercial de un producto y su estructura técnica son conceptos diferentes. --- ## 2. Product Type no significa categoría Este es uno de los errores conceptuales más fáciles de cometer. Un **Product Type** define principalmente la estructura y comportamiento de un tipo de Product. Una **categoría** clasifica productos. Por ejemplo: ```plaintext Categorías Electronics ├── Computers ├── Phones ├── Tablets └── Accessories ``` No necesariamente necesitamos cuatro Product Types. Si todos comparten una estructura compatible, podemos tener: ```plaintext Product Type Electronic Product Taxonomy Product Category ├── Computers ├── Phones ├── Tablets └── Accessories ``` En cambio, podríamos justificar Product Types diferentes cuando los productos necesitan estructuras claramente diferentes. Por ejemplo: ```plaintext Physical Book Fields: ├── Author ├── Publisher ├── ISBN ├── Number of pages └── Description Online Course Fields: ├── Instructor ├── Duration ├── Difficulty level ├── Course curriculum └── Description ``` Aquí existe una diferencia estructural real. --- ## 3. Cuándo crear un Product Type diferente Podemos utilizar varias preguntas para tomar esta decisión. ¿Los productos necesitan: - Campos significativamente diferentes? - Variation Types diferentes? - Interfaces administrativas diferentes? - Displays significativamente diferentes? - Comportamientos comerciales diferentes? - Procesos específicos asociados al tipo de producto? Si la respuesta es afirmativa para varias de estas preguntas, probablemente estamos ante Product Types diferentes. Por ejemplo: ```plaintext Product Type: Physical Product ├── Description ├── Brand ├── Category └── Documentation Product Type: Software ├── Description ├── System requirements ├── Supported platforms └── Documentation ``` La regla práctica puede expresarse así: ```plaintext ¿Solo cambia la clasificación? ↓ Probablemente Taxonomy ¿Cambia la estructura del producto? ↓ Probablemente Product Type ``` --- ## 4. Product frente a Product Variation Una vez definido el Product Type debemos separar correctamente el producto conceptual de aquello que realmente se vende. Por ejemplo: ```plaintext Product Classic T-Shirt ``` puede tener: ```plaintext Variations ├── Black / S ├── Black / M ├── Black / L ├── White / S ├── White / M └── White / L ``` El Product representa: ```plaintext Classic T-Shirt ``` La Variation representa: ```plaintext Classic T-Shirt Black Medium SKU: TS-BLK-M Price: 24.90 EUR ``` Una forma sencilla de recordarlo es: ```plaintext Product = qué producto es Variation = cuál versión concreta compramos ``` --- ## 5. Decidir dónde colocar un campo Una de las preguntas más frecuentes durante el modelado es: > ¿Este campo debería estar en el Product o en la Product Variation? Existe una pregunta muy útil para resolverlo: > ¿Este valor es común para todas las variaciones o puede cambiar entre ellas? Supongamos este producto: ```plaintext Product Running Shoe X100 Variations ├── Black / 42 ├── Black / 43 ├── Blue / 42 └── Blue / 43 ``` Podríamos almacenar en Product: ```plaintext Title Description Brand Product family Technical documentation Category ``` Y en Product Variation: ```plaintext SKU Price Color Size Weight Variation image ``` Podemos resumir: ```plaintext ¿Es común a todas las variaciones? ↓ Product ¿Puede cambiar según lo que compramos? ↓ Product Variation ``` --- ## 6. Las imágenes son un buen ejemplo Las imágenes muestran por qué no existe una regla absoluta sobre dónde debe vivir un campo. Supongamos que todas las variaciones utilizan las mismas fotografías. ```plaintext Product Running Shoe X100 Images: ├── front.jpg ├── side.jpg └── sole.jpg ``` En ese caso parece lógico almacenar las imágenes en el Product. Pero si tenemos: ```plaintext Variation Black ↓ black-front.jpg black-side.jpg Variation Blue ↓ blue-front.jpg blue-side.jpg ``` entonces las imágenes están asociadas a la Variation. La pregunta no es: > ¿Dónde suelen almacenarse las imágenes en Commerce? Sino: > ¿Qué entidad describe realmente esta imagen? --- ## 7. Product Variation Type Las Product Variations también tienen su propia estructura. Esta estructura se define mediante un **Product Variation Type**. Por ejemplo: ```plaintext Product Type Clothing │ ▼ Variation Type Clothing Variation Fields / attributes: ├── Color ├── Size ├── SKU ├── Price └── Weight ``` Otro Product Type podría necesitar: ```plaintext Product Type Laptop │ ▼ Variation Type Laptop Configuration Fields / attributes: ├── RAM ├── Storage ├── Keyboard ├── SKU ├── Price └── Weight ``` La estructura de la unidad comprable es diferente y por eso puede resultar apropiado utilizar Variation Types diferentes. --- ## 8. Cuándo crear un Variation Type diferente Podemos plantearnos: - ¿Las variaciones tienen atributos diferentes? - ¿Necesitan campos comerciales diferentes? - ¿Necesitan un Order Item Type diferente? - ¿Representan unidades comprables estructuralmente distintas? Por ejemplo: ```plaintext Clothing Variation Attributes: ├── Color └── Size Book Variation Attribute: └── Format Laptop Variation Attributes: ├── RAM ├── Storage └── Keyboard layout ``` En este caso tiene sentido separar los Variation Types. Pero si dos familias de productos utilizan exactamente la misma estructura de variaciones, crear dos Variation Types diferentes puede añadir complejidad sin aportar valor. --- ## 9. Product Attributes Un **Product Attribute** representa una propiedad utilizada para diferenciar y seleccionar Product Variations. El ejemplo clásico es una camiseta. ```plaintext Attribute: Color ├── Black ├── White └── Blue Attribute: Size ├── S ├── M ├── L └── XL ``` Estas opciones pueden producir variaciones: ```plaintext Black / S Black / M Black / L White / S White / M White / L Blue / S Blue / M Blue / L ``` Cuando el usuario selecciona: ```plaintext Color: Blue Size: M ``` Commerce puede determinar qué Product Variation representa esa combinación. --- ## 10. Attribute no significa propiedad Es importante no interpretar la palabra *Attribute* de Drupal Commerce como cualquier atributo descriptivo del producto. Un portátil puede tener características como: ```plaintext Manufacturer: Lenovo Processor: Intel Core Ultra Screen technology: OLED Wi-Fi: Wi-Fi 7 ``` Esto no significa que debamos crear Product Attributes para todas ellas. Si el cliente no selecciona entre esas propiedades para elegir una Variation, pueden ser simplemente fields. En cambio: ```plaintext RAM ├── 16 GB └── 32 GB Storage ├── 512 GB ├── 1 TB └── 2 TB ``` pueden funcionar perfectamente como Attributes si representan opciones que determinan la variación comprable. Podemos utilizar esta pregunta: > ¿El usuario selecciona este valor para determinar qué Variation está comprando? Si la respuesta es sí, probablemente estamos ante un Product Attribute. --- ## 11. Attribute frente a Field Comparemos ambos conceptos. ### Product Attribute Participa en la selección entre Product Variations. ```plaintext Size Color Storage RAM Format ``` ### Field Almacena información acerca del Product o Variation. ```plaintext Manufacturer Technical description EAN Weight Manual Release date ``` Un mismo concepto puede ser Attribute en una tienda y field en otra. Por ejemplo, **Color**. En una tienda de camisetas: ```plaintext Color ↓ Attribute El comprador selecciona: Black / White / Blue ``` Pero en una tienda de maquinaria podría existir: ```plaintext Machine color: Industrial Gray ``` sin que el comprador pueda escogerlo. Entonces puede ser simplemente un field descriptivo. El modelo depende del negocio, no del nombre del dato. --- ## 12. Attributes frente a opciones personalizadas Existe otra distinción muy importante. Supongamos que vendemos una camiseta personalizada. El cliente selecciona: ```plaintext Color: Black Size: M Custom text: "Drupal Camp 2026" ``` Color y Size pueden determinar una Variation: ```plaintext Black / M SKU: SHIRT-BLK-M ``` Pero no queremos generar previamente una Variation para cada posible texto. ```plaintext SHIRT-BLK-M-DANIEL SHIRT-BLK-M-MARIA SHIRT-BLK-M-DRUPAL ... ``` El texto es información propia de la compra. Conceptualmente: ```plaintext Opción conocida previamente que identifica lo que vendemos ↓ Attribute / Variation Dato proporcionado específicamente para esta compra ↓ Order Item ``` Esta diferencia se vuelve especialmente importante cuando trabajamos con productos personalizados. --- ## 13. Fields frente a Taxonomy Otra decisión habitual en Drupal es determinar cuándo utilizar un field simple y cuándo utilizar una Taxonomy. Supongamos que queremos almacenar la marca. Podríamos crear: ```plaintext Text field: Brand = "Lenovo" ``` Pero también podríamos crear: ```plaintext Taxonomy: Brand ├── Apple ├── Dell ├── HP ├── Lenovo └── Microsoft ``` La segunda opción puede ser mucho más útil si necesitamos: - Reutilizar valores - Evitar diferentes formas de escribir el mismo valor - Filtrar productos - Crear páginas de marca - Añadir metadata a una marca - Relacionar otros contenidos con esa marca --- ## 14. Cuándo utilizar Taxonomy Taxonomy suele ser una buena solución cuando tenemos un conjunto reutilizable y administrable de conceptos. Por ejemplo: ```plaintext Product Category Brand Product Family Collection Application Industry ``` Una Taxonomy también puede tener estructura jerárquica. ```plaintext Product Category Electronics ├── Computers │ ├── Laptops │ └── Desktops │ ├── Tablets └── Smartphones ``` Esto puede resultar especialmente útil para navegación y filtros. --- ## 15. Cuándo no utilizar Taxonomy Taxonomy no debería convertirse automáticamente en el lugar donde almacenamos cualquier lista de valores. Por ejemplo: ```plaintext Weight: 1.42 kg Width: 32 cm Warranty: 24 months Release year: 2026 ``` Probablemente estos datos deberían utilizar tipos de campo apropiados. Crear vocabularios como: ```plaintext Weight ├── 1.4 kg ├── 1.42 kg ├── 1.45 kg └── 1.5 kg ``` normalmente no tendría sentido. Podemos preguntarnos: > ¿Estamos representando un concepto reutilizable o simplemente almacenando un valor? Si estamos almacenando un valor, probablemente necesitamos un field. --- ## 16. Taxonomy frente a Product Attribute Estos dos conceptos también pueden parecer similares. Supongamos que tenemos colores. Podríamos utilizar Color para clasificar productos: ```plaintext Color classification ├── Black ├── Blue └── White ``` O utilizarlo como Attribute para seleccionar una Variation: ```plaintext Product Classic T-Shirt Select color: [ Black ▼ ] Select size: [ M ▼ ] ``` La pregunta nuevamente es funcional: > ¿Estamos clasificando el producto o seleccionando la unidad concreta que queremos comprar? ```plaintext Clasificar / navegar / filtrar ↓ Taxonomy Seleccionar una Variation ↓ Product Attribute ``` Dependiendo del proyecto, puede existir relación entre ambos conceptos, pero no debemos asumir que son equivalentes. --- ## 17. Un ejemplo más completo: tienda de laptops Supongamos que queremos construir una tienda de laptops. Tenemos estos productos: ```plaintext ThinkPad X1 Carbon ThinkPad T14 MacBook Air MacBook Pro Dell XPS 13 ``` Podríamos comenzar con: ```plaintext Product Type: Laptop ``` Campos del Product: ```plaintext Title Description Brand Product family Processor family Screen size Technical specifications Documentation General images Category ``` Variation Type: ```plaintext Laptop Configuration ``` Attributes: ```plaintext RAM ├── 16 GB ├── 24 GB └── 32 GB Storage ├── 512 GB ├── 1 TB └── 2 TB ``` Campos de Variation: ```plaintext SKU Price Weight EAN Specific image Availability data ``` Taxonomies: ```plaintext Brand ├── Apple ├── Dell └── Lenovo Product Category Electronics └── Computers └── Laptops ``` Podríamos terminar con: ```plaintext Product ThinkPad X1 Carbon Brand Lenovo Category Laptops Variations ├── 16 GB / 512 GB │ ├── SKU: X1-16-512 │ └── Price: 1,399 EUR │ ├── 16 GB / 1 TB │ ├── SKU: X1-16-1TB │ └── Price: 1,549 EUR │ └── 32 GB / 1 TB ├── SKU: X1-32-1TB └── Price: 1,749 EUR ``` Este modelo separa claramente: - Identidad del producto - Clasificación - Información descriptiva - Opciones comerciales - Unidad vendible --- ## 18. Segundo ejemplo: tienda de libros Supongamos ahora una librería. El producto es: ```plaintext Clean Architecture Robert C. Martin ``` Podríamos tener: ```plaintext Product Type Book ``` Fields: ```plaintext Author Description Publisher Publication date Language Category Cover ``` Variation Type: ```plaintext Book Format ``` Attribute: ```plaintext Format ├── Hardcover ├── Paperback └── eBook ``` Variations: ```plaintext Hardcover ├── SKU: BOOK-100-HC ├── Price: 39 EUR └── ISBN: ... Paperback ├── SKU: BOOK-100-PB ├── Price: 29 EUR └── ISBN: ... eBook ├── SKU: BOOK-100-EB └── Price: 19 EUR ``` En este modelo, Hardcover, Paperback y eBook no son necesariamente tres Products independientes. Pueden ser tres formas comprables del mismo Product. --- ## 19. Tercer ejemplo: producto sin opciones No todos los productos necesitan múltiples variaciones. Supongamos: ```plaintext Product Drupal Commerce Handbook ``` Solo existe una edición. Podemos tener: ```plaintext Product Drupal Commerce Handbook └── Variation ├── SKU: DCH-001 └── Price: 39 EUR ``` No necesitamos inventar Attributes. La Variation sigue siendo necesaria porque representa la entidad comprable, pero puede existir una sola. ```plaintext 1 Product ↓ 1 Variation ``` Una buena arquitectura no necesita ser compleja cuando el negocio no lo es. --- ## 20. Cuidado con la explosión de variaciones Los Attributes pueden generar muchas combinaciones. Supongamos: ```plaintext 10 colores × 8 tamaños × 5 materiales ``` Tenemos potencialmente: ```plaintext 10 × 8 × 5 = 400 variaciones ``` Si añadimos: ```plaintext 4 acabados ``` pasamos a: ```plaintext 1.600 combinaciones ``` Esto debería hacernos preguntar si todas esas opciones representan realmente unidades comerciales diferentes. Una propiedad debería convertirse en parte de una Variation cuando exista una razón comercial para ello, por ejemplo: - SKU diferente - Precio diferente - Stock independiente - Peso diferente - Disponibilidad independiente - Integración independiente con ERP Si una opción es simplemente una personalización del pedido, quizás no debería multiplicar el número de Variations. --- ## 21. El SKU como pista de modelado Una pregunta particularmente útil durante el Discovery es: > ¿Esta combinación tiene un SKU propio en el negocio? Por ejemplo: ```plaintext Black / Small SKU: TS-BLK-S Black / Medium SKU: TS-BLK-M Blue / Small SKU: TS-BLU-S ``` Esto es una indicación fuerte de que estamos ante Product Variations diferentes. Sin embargo, el SKU no debería ser nuestra única regla. Podemos encontrar negocios donde la identificación comercial provenga de un ERP u otro sistema externo y necesitemos considerar también inventario, pricing y fulfillment. --- ## 22. Pensar también en el ERP o PIM En proyectos reales, el catálogo puede no originarse en Drupal Commerce. Podemos tener: ```plaintext PIM ↓ Product information ↓ Drupal Commerce ERP ↓ SKU Price Stock ↓ Drupal Commerce ``` En ese caso nuestro modelo debería intentar representar correctamente la estructura del sistema que actúa como Source of Truth. Por ejemplo: ```plaintext PIM Product ↓ Commerce Product ERP Article / SKU ↓ Commerce Product Variation ``` Si el ERP diferencia dos artículos mediante SKU independientes, puede ser una señal importante para nuestro modelo de Variations. Diseñar Commerce sin comprender estas relaciones puede generar integraciones innecesariamente complejas. --- ## 23. Diseñar pensando en búsqueda y filtros El modelo de catálogo también afecta directamente a la experiencia del usuario. Supongamos que necesitamos filtros: ```plaintext Brand Category Price Color Size Material Availability ``` Debemos saber dónde vive cada dato. ```plaintext Brand → Product taxonomy Category → Product taxonomy Price → Variation Color → Variation attribute Size → Variation attribute Material → Product field / taxonomy / attribute dependiendo del modelo Availability → Variation / inventory system ``` Esta decisión posteriormente tendrá consecuencias sobre Search API, Views, Facets y la forma en que agregamos información procedente de múltiples Variations. Por eso la arquitectura del catálogo debe diseñarse antes de construir los filtros. --- ## 24. Diseñar pensando en el editor Una arquitectura técnicamente correcta también debe ser fácil de administrar. Supongamos que un editor necesita crear 500 productos. Debemos preguntarnos: - ¿Cuántos campos deberá completar? - ¿Qué campos son obligatorios? - ¿Qué valores pueden reutilizarse? - ¿Cómo creará las variaciones? - ¿Quién mantiene los Attributes? - ¿Quién mantiene las Taxonomies? - ¿Los productos se crean manualmente o se importan? Un modelo muy elegante desde el punto de vista técnico puede ser un problema si requiere un proceso editorial innecesariamente complicado. El modelo debe funcionar tanto para el comprador como para quien administra el catálogo. --- ## 25. Diseñar pensando en traducciones En proyectos multilingües debemos identificar qué información necesita traducción. Por ejemplo: ```plaintext Product Title Description Technical content ↓ Translatable ``` Mientras que: ```plaintext SKU Price EAN Weight ↓ Normalmente no dependen del idioma ``` Los términos utilizados para clasificación también pueden necesitar traducción: ```plaintext Category DE: Werkzeuge EN: Tools ES: Herramientas ``` Este análisis es especialmente importante cuando Commerce se utiliza en varios países o idiomas. --- ## 26. Una matriz para decidir dónde vive cada dato Podemos utilizar una matriz conceptual sencilla. ```plaintext ¿Describe el producto en general? ↓ Product field ¿Clasifica productos? ↓ Taxonomy ¿Diferencia unidades comprables? ↓ Product Attribute / Variation ¿Es información propia de la unidad comprable? ↓ Variation field ¿Es proporcionado por el comprador para esta compra? ↓ Order Item field ``` Podemos aplicarla a algunos ejemplos: ```plaintext Descripción → Product Marca → Taxonomy / Product Categoría → Taxonomy / Product Color seleccionable → Product Attribute / Variation SKU → Variation Precio → Variation Peso específico → Variation Manual técnico común → Product Texto para grabado → Order Item Mensaje de regalo → Order Item ``` --- ## 27. Evitar duplicar información Un buen modelo debería intentar mantener cada dato en un único lugar lógico. Por ejemplo, si Brand pertenece al Product: ```plaintext Product Brand: Lenovo Variations ├── 16 GB / 512 GB ├── 16 GB / 1 TB └── 32 GB / 1 TB ``` no necesitamos repetir: ```plaintext Variation 1 Brand: Lenovo Variation 2 Brand: Lenovo Variation 3 Brand: Lenovo ``` La duplicación dificulta: - Edición - Importación - Sincronización - Validación - Mantenimiento La información debería vivir en el nivel más alto donde continúe siendo verdadera. Si un valor es común a todas las Variations, normalmente pertenece al Product. --- ## 28. No modelar pensando solamente en la página Otro error frecuente es diseñar las entidades pensando únicamente en cómo queremos mostrar una página. Por ejemplo: > Necesito mostrar estos datos juntos, por tanto deben estar en la misma entidad. No necesariamente. Drupal puede presentar información procedente de diferentes entidades. Una página de producto puede combinar: ```plaintext Product ├── Title ├── Description ├── Brand └── Category Current Variation ├── Price ├── SKU ├── Image └── Availability Related content ├── Documentation ├── Reviews └── Related products ``` El modelo debe representar correctamente el dominio. La capa de presentación puede posteriormente combinar esos datos. --- ## 29. Un proceso práctico para diseñar el catálogo Antes de configurar Commerce podemos seguir este proceso. ### Paso 1: listar las familias de productos ```plaintext Laptops Phones Accessories Software ``` ### Paso 2: listar la información necesaria ```plaintext Title Brand Description Category RAM Storage Color SKU Price Weight ``` ### Paso 3: identificar qué información es común ```plaintext Product Title Brand Description Category ``` ### Paso 4: identificar qué cambia entre unidades vendibles ```plaintext Variation RAM Storage Color SKU Price Weight ``` ### Paso 5: identificar las opciones que selecciona el comprador ```plaintext Attributes RAM Storage Color ``` ### Paso 6: identificar clasificaciones reutilizables ```plaintext Taxonomies Brand Category ``` ### Paso 7: decidir Product Types y Variation Types Solamente ahora decidimos cuántos tipos necesitamos. --- ## 30. Checklist de modelado del catálogo Antes de empezar la configuración deberíamos poder responder: ### Products - ¿Qué representa un Product? - ¿Qué información es común a todas sus Variations? - ¿Cuántos Product Types necesitamos realmente? ### Variations - ¿Qué constituye una unidad vendible? - ¿Qué provoca que necesitemos una Variation diferente? - ¿Las Variations tienen SKU independiente? - ¿Tienen precio independiente? - ¿Tienen stock independiente? ### Attributes - ¿Qué opciones selecciona el comprador? - ¿Qué opciones determinan una Variation? - ¿Todas las combinaciones existen realmente? ### Fields - ¿El dato pertenece al Product o a la Variation? - ¿Cuál es el tipo de campo apropiado? - ¿Necesita traducción? ### Taxonomies - ¿Qué conceptos reutilizamos? - ¿Necesitamos jerarquías? - ¿Necesitamos utilizarlos para navegación o filtros? ### Integraciones - ¿Existe PIM? - ¿Existe ERP? - ¿Dónde se originan productos y SKUs? - ¿Qué sistema es Source of Truth para cada dato? --- ## 31. La regla de las cinco preguntas Podemos resumir gran parte del modelado del catálogo utilizando cinco preguntas. ```plaintext 1. ¿Qué producto presentamos? ↓ Product 2. ¿Qué unidad concreta vendemos? ↓ Product Variation 3. ¿Qué selecciona el usuario para determinar esa unidad? ↓ Product Attribute 4. ¿Cómo clasificamos el producto? ↓ Taxonomy 5. ¿Qué información simplemente describe una entidad? ↓ Field ``` Estas cinco preguntas resuelven una gran parte de las decisiones iniciales de arquitectura. --- ## Conclusión Modelar correctamente el catálogo es una de las habilidades más importantes al trabajar con Drupal Commerce. El objetivo no es crear tantas estructuras como sea posible, sino encontrar el modelo más sencillo que represente correctamente el negocio. Podemos resumir las responsabilidades principales así: ```plaintext Product Type = estructura de una familia de productos Product = producto conceptual presentado al usuario Variation Type = estructura de las unidades comprables Product Variation = unidad concreta que puede comprarse Product Attribute = opción que permite seleccionar una Variation Taxonomy = clasificación reutilizable Field = dato estructurado de una entidad ``` Y podemos utilizar una regla adicional: > No crees una nueva estructura porque los datos se llamen diferente. Créala cuando el negocio necesite una estructura o comportamiento diferente. Un catálogo bien diseñado simplificará prácticamente todo lo que construiremos después: búsqueda, filtros, precios, inventario, importaciones, integraciones, checkout y administración. Una vez definido correctamente qué vendemos y cómo representamos nuestros productos, podemos avanzar hacia otra de las partes centrales de Drupal Commerce: **precios y ajustes**. En el siguiente artículo estudiaremos cómo Commerce representa el precio, dónde se almacena, cómo distinguir precio base y precio final, y cómo intervienen promociones, impuestos y otros adjustments en el cálculo de un pedido. ## Course navigation: Drupal Commerce Chapter 4 of 11 - [ ← Anterior Arquitectura de Drupal Commerce: Stores, Products, Variations, Orders y sus relaciones ](/es/arquitectura-de-drupal-commerce-stores-products-variations-orders-y-sus-relaciones) - [ Siguiente → Precios en Drupal Commerce: Price, Adjustments, Promotions e Impuestos ](/es/precios-en-drupal-commerce-price-adjustments-promotions-e-impuestos) [↑ Course index](/es/node/43)