Cloud Sandbox

bfstore · Domain Model

Domain Concepts & Relationships

The business concepts Borough Furniture Store must understand, the responsibility areas that govern them and the conceptual relationships that preserve meaning across the purchase journey.

Last updated:

Why Concepts And Relationships Matter

Borough Furniture Store needs one shared understanding of the concepts that make commerce possible. A Product is not the same thing as a purchasable Variant. A Basket is not an Order waiting for a different status value. A Payment Attempt is not the retailer's accepted purchase record. A Shipment describes fulfilment work, not the commercial agreement represented by an Order.

Making those distinctions explicit prevents accidental coupling. Contracts, data models and workflows can evolve without quietly changing the business meaning of the concepts they carry.

Domain Concept A business idea with a stable meaning, identity, value or lifecycle that bfstore must understand.
Conceptual Relationship A business-level statement explaining how two concepts participate in the same outcome without prescribing storage or communication.
Value Concept A meaning-rich value such as Money, Quantity or Address that is identified by its attributes rather than by an independent lifecycle.

The Question This Page Answers

What important business concepts must bfstore understand, which responsibility area governs each one and what must remain true when those concepts refer to, contain, derive from or preserve information about one another?

Concepts At A Glance

The Domain Concept Map

The map follows the purchase journey while keeping authoritative concepts, coordination concepts, shared values and derived experience concepts visually distinct. The lines describe conceptual relationships rather than runtime communication.

Grounded In The V1 Slice Target Lifecycle Concept Shared Value Concept Derived Or Supporting Concept

Borough Furniture Store Domain Concept Map

A domain concept map. Product contains Variants and is classified by Category. Basket contains Basket Items that reference a Variant. Checkout Attempt uses a Basket and coordinates a Reservation and Payment Attempt before producing an Order. Order contains Order Items that preserve purchased Product and Variant information. Order leads to Shipment and Notification. Search Projection, Review and Recommendation derive from or reference governed concepts. Shared value concepts include Identifier, Money, Quantity, Address and Timestamp.
The conceptual model distinguishes current Catalog and Basket concepts from planned purchase, fulfilment and supporting concepts. Relationship labels describe business meaning, not database or protocol design.

Concept Families

Product & Merchandising Concepts

Describe what the retailer offers and how a purchasable choice is understood.

  • Product
  • Variant
  • Category
  • Attribute
  • Product Image
  • Product State
Primary Owner
Catalog.
Key Distinction
A Product describes the customer-facing item; a Variant is the specific purchasable configuration.
Grounded In Current Catalog

Selection Concepts

Describe mutable customer intent before purchase commitment.

  • Basket
  • Basket Item
  • Quantity
  • Product Reference
  • Variant Reference
Primary Owner
Basket.
Key Distinction
A Basket records current selection intent; it is not authoritative evidence that stock, payment or an Order exists.
Grounded In Current Basket Slice

Purchase Commitment Concepts

Describe the work and durable outcomes required to turn a Basket into an accepted purchase.

  • Checkout Attempt
  • Reservation
  • Payment Attempt
  • Order
  • Order Item
Primary Owners
Checkout Coordination, Inventory, Payment And Order.
Key Distinction
Coordination progress, stock allocation, payment outcome and accepted purchase are separate concepts.
Planned

Fulfilment & Communication Concepts

Describe the work needed after purchase commitment and the messages produced from important outcomes.

  • Shipment
  • Delivery Reference
  • Notification
  • Message Intent
  • Delivery State
Primary Owners
Fulfilment And Notification.
Key Distinction
A Shipment is not an Order, and a Notification is not the outcome it describes.
Planned

Insight & Relevance Concepts

Improve product discovery and customer confidence without replacing authoritative commerce concepts.

  • Search Projection
  • Review
  • Recommendation
  • Relevance Signal
  • Model Or Ruleset Version
Primary Owners
Search, Review And Recommendation.
Key Distinction
Derived concepts may optimise experience but cannot redefine Product, Variant or Order truth.
Planned Supporting Concepts

Shared Value Concepts

Carry stable meaning across responsibility areas without becoming shared mutable business records.

  • Identifier
  • Money
  • Quantity
  • Address
  • Contact Point
  • Timestamp
Ownership Rule
Each area owns the value within its own record and context.
Key Distinction
Shared definition does not imply a shared database row or universal mutable object.
Definition To Be Standardised

The Concept Catalogue

Stable concept identifiers allow later requirements, lifecycle diagrams, service dossiers, contracts and tests to refer to the same business meaning. The catalogue remains conceptual and does not dictate code type names.

Borough Furniture Store Domain Concept Catalogue
Concept ID Concept Meaning Authoritative Area Current Status
DC-CAT-001 Product The customer-facing commercial item described by the retailer. Catalog Implemented V1
DC-CAT-002 Variant A specific purchasable configuration of a Product. Catalog Implemented V1
DC-CAT-003 Category A governed classification used to organise Products and interpret category-scoped Attributes. Catalog Implemented V1
DC-BAS-001 Basket A customer's mutable pre-purchase selection and its current state. Basket Implemented V1
DC-BAS-002 Basket Item A selected Variant reference, Quantity and any Basket-owned selection data. Basket Implemented V1
DC-CHK-001 Checkout Attempt The tracked effort to turn a valid Basket selection into a committed purchase. Checkout Coordination Planned
DC-INV-001 Reservation A time-bounded allocation of stock to a purchase attempt or accepted Order. Inventory Planned
DC-PAY-001 Payment Attempt bfstore's record of an attempt to obtain a recognised payment outcome. Payment Planned
DC-ORD-001 Order The retailer's authoritative record of an accepted purchase. Order Planned
DC-ORD-002 Order Item A committed purchased line preserving the commercial meaning needed after Catalog changes. Order Planned
DC-FUL-001 Shipment The retailer's record of fulfilment work for all or part of an accepted Order. Fulfilment Planned
DC-NOT-001 Notification A controlled message intent and its delivery state. Notification Planned
DC-SRC-001 Search Projection A derived representation optimised for search and recoverable from governed sources. Search Planned
DC-REV-001 Review Supported customer feedback with provenance and moderation state. Review Planned
DC-REC-001 Recommendation A product suggestion produced by a known model, ruleset or evidence context. Recommendation Planned

Relationship Types

Containment One concept owns a collection or part whose meaning belongs within the containing concept, such as a Basket containing Basket Items.
Reference One area records the identity of a concept owned elsewhere, such as a Basket Item referencing a Variant.
Snapshot A concept preserves selected information as it was understood at a significant business moment, such as an Order Item preserving purchased details.
Derivation A supporting concept is produced from authoritative inputs and can be rebuilt or recalculated, such as a Search Projection derived from Catalog information.
Important Conceptual Relationships
From Concept Relationship To Concept Business Meaning
Product Contains Variant A Product may offer several specific purchasable configurations.
Product Is Classified By Category Category provides governed organisation and attribute context.
Basket Contains Basket Item Basket owns its mutable collection of customer selections.
Basket Item References Variant The selection points to a Catalog-owned purchasable choice without owning Variant truth.
Checkout Attempt Uses Basket Checkout begins from a known selection but does not turn the Basket itself into an Order.
Checkout Attempt Coordinates Reservation And Payment Attempt Purchase commitment depends on stock and payment outcomes owned by separate areas.
Order Contains Order Item Order owns committed purchased lines after acceptance.
Order Item Preserves A Snapshot Of Product And Variant Information Later Catalog changes must not rewrite the meaning of the accepted purchase.
Shipment Fulfils Order Or Order Items Fulfilment work progresses the accepted purchase without owning Order truth.
Notification Describes Order, Payment Or Shipment Outcome The message communicates an outcome but does not create or change it.
Search Projection Derives From Product And Variant Search optimises discovery while remaining recoverable from Catalog truth.

The Purchase Relationship Chain

The purchase journey connects concepts owned by several responsibility areas. The chain below expresses the conceptual progression without deciding whether later implementation uses synchronous calls, events, orchestration or choreography.

  1. Product
  2. Variant
  3. Basket Item
  4. Basket
  5. Checkout Attempt
  6. Reservation + Payment Attempt
  7. Order + Order Items
  8. Shipment + Notification

Selection Is Not Commitment

Basket concepts describe customer intent that can still change. Order concepts describe an accepted purchase whose commercial meaning must be preserved.

Provider Outcome Is Not Domain Ownership

A Payment Provider or Delivery Provider contributes external information. Payment and Fulfilment still own the bfstore concepts that interpret and preserve those outcomes.

Derived Experience Is Not Authoritative Truth

Search and Recommendation may copy identifiers and customer-facing information for fast retrieval or ranking. They do not become the authority for whether a Variant exists, is active or is purchasable.

Identity, References And Snapshots

  • Identity Must Survive Movement A concept identifier should remain stable when the concept crosses a contract, appears in evidence or is referenced by another responsibility area.
  • A Reference Is Not A Shared Record Referencing another area's identifier does not permit direct mutation or imply a cross-service database relationship.
  • Snapshots Preserve Historical Meaning Committed records should retain the information required to explain the business outcome even when the current source concept later changes.
Identity, Reference And Snapshot Decisions
Situation Preferred Conceptual Treatment Reason Detailed Later In
Basket Selects A Variant Reference the Catalog-owned Variant identity and retain only Basket-owned selection data. Catalog remains authoritative while Basket owns mutable selection. Basket Service, Catalog Service And Communication & Contracts.
Order Records A Purchased Item Reference relevant identities and preserve a committed commercial snapshot. The accepted purchase must remain explainable after Product or price changes. Order Service, Data & Persistence And Checkout Workflow.
Search Indexes A Product Create a derived projection with source identity and rebuild information. Search should recover from governed sources and never become Product truth. Search Service, Event Architecture And Projection Recovery.
Notification Describes An Order Reference the outcome and retain the message-specific evidence required for delivery. Notification owns communication state, not Order state. Notification Service And Customer Communication Workflow.

Conceptual Model Boundaries

What This Conceptual Model Includes And Defers
Concern Included Here Deferred To Later Documentation
Concept Meaning Business definition, distinction, owner and relationship. Code type, package, protobuf message and database representation.
Identity Which concepts require stable identity and where references preserve ownership. Identifier syntax, generation, storage type and indexing strategy.
Relationship Containment, reference, snapshot, derivation and business dependency. Foreign keys, RPCs, events, joins, projections and consistency mechanism.
Lifecycle Which concepts have meaningful state and need lifecycle modelling. Full transition diagrams, commands, events and compensation behaviour.
Shared Values Provider-neutral meaning for Money, Quantity, Address and related values. Serialization, validation libraries and provider-specific address handling.

Repository And Evidence

The bfstore repository provides current implementation evidence for the grounded concepts. The Catalog service documentation explicitly identifies Products, Categories, Product Variants, Product Images and Catalog Attributes as owned information while excluding Basket, Inventory, Order, Payment, Shipping, Notification, Review, Recommendation and Search responsibilities.

The website's target model adds the planned concepts needed for checkout, fulfilment and supporting experiences. Those concepts remain planned until their contracts, code, persistence, tests and runtime evidence exist. Later repository tidy-up should connect implemented types and schemas back to the concept catalogue rather than treating code names as the definition of the domain.

Continue Exploring

With the concepts and their relationships defined, the next page describes how lifecycle-bearing concepts move through valid states and which transitions the business must reject.

Domain Areas & Responsibilities Business Lifecycles Domain Model