Why The Domain Model Matters
Business Context establishes the retailer, its participants and the outcomes it must be able to produce. The Domain Model turns that context into a coherent conceptual language for the application. It identifies the areas of responsibility within the business, the concepts each area reasons about and the relationships and state changes that make the commerce journey meaningful.
This model gives later architecture a stable problem space. Service boundaries can change as the implementation matures, but the meaning of a Product, Basket, Order, Payment or Shipment should not drift casually between code, requirements, diagrams and operational evidence.
The Role Of This Topic
The Domain Model is the bridge between business capabilities and application architecture. It provides the responsibility and language model that later pages use to design service ownership, data boundaries, contracts, events, workflows, validation and tests.
Domain Model At A Glance
Explore The Domain Model
The Domain Model is divided into four focused pages. Each page answers a different modelling question without forcing conceptual, lifecycle and vocabulary concerns into one giant scroll-creature.
Identify the major areas of business responsibility, the decisions each area makes and the concepts it governs without treating those areas as automatic microservices.
Domain Concepts & RelationshipsDescribe The Business Concepts bfstore UnderstandsDefine concepts such as Product, Variant, Basket, Order, Payment and Shipment and show their conceptual relationships without producing a physical database model.
Business LifecyclesMake Valid State Change ExplicitDescribe the meaningful states and transitions of Baskets, Orders, Payments, Shipments and other lifecycle-bearing concepts.
Domain VocabularyGive Important Terms One Shared MeaningMaintain the provider-neutral vocabulary used by business pages, requirements, contracts, code, diagrams and operational evidence.
The High-Level Domain Map
The map below shows the current conceptual landscape. It groups related business responsibilities and highlights the concepts that connect them. The relationships are intentionally business-level. They are not RPC arrows, event topics, foreign keys or deployment dependencies.
Borough Furniture Store High-Level Domain Map
What The Domain Model Establishes
| Model View | Primary Question | Produces | Used Later By |
|---|---|---|---|
| Domain Areas & Responsibilities | Which business decisions and concepts belong together? | Responsibility map, ownership questions and boundary candidates. | Service Boundaries & Ownership, Data Ownership And Team Responsibilities. |
| Domain Concepts & Relationships | What business ideas must bfstore understand and how are they related? | Concept catalogue and conceptual relationship model. | Contracts, Data & Persistence, Service Dossiers And Tests. |
| Business Lifecycles | How do important concepts change over time? | Valid states, transitions, terminal outcomes and invalid moves. | Business Rules, APIs, Events, Workflows, Failure Handling And Tests. |
| Domain Vocabulary | What does each important business term mean? | Shared definitions, preferred terms and distinctions. | Every Business, Architecture, Service, Operations And Evidence Page. |
A Model Of Meaning And Responsibility
The Domain Model should make it possible to explain who owns a decision, what concepts participate in that decision and which rules must remain true. It should not simply redraw the repository directory tree with more elegant boxes.
From Capabilities To Responsibilities
Business capabilities describe the outcomes the retailer must produce. Domain responsibilities identify the coherent areas of business knowledge and decision making needed to produce those outcomes.
- Business Capability
- Business Decisions
- Domain Concepts
- Rules And Invariants
- Domain Responsibility
- Boundary Candidate
- Implementation Evidence
| Business Capability | Domain Decisions | Important Concepts | Responsibility Areas Involved |
|---|---|---|---|
| Product Discovery | Which products and variants are visible and understandable to customers? | Product, Variant, Category, Attribute And Availability View | Catalog, Search And Recommendation |
| Basket Management | Which valid selections belong in the customer's mutable pre-purchase state? | Basket, Basket Item, Product Reference, Variant Reference And Quantity | Basket With Product Validation From Catalog |
| Checkout | Can the current selection become a committed purchase, and what outcomes are required? | Checkout Attempt, Reservation, Payment Attempt And Order | Checkout Coordination, Inventory, Payment And Order |
| Order Fulfilment | What work is required to move an accepted purchase toward delivery? | Order, Shipment, Delivery Reference And Notification | Order, Shipping, Delivery Coordination And Notification |
Modelling Boundaries
- Business Meaning Before Technical Shape Define what a concept means and which decisions surround it before assigning it to a service, schema or event.
- Ownership Without Premature Deployment A responsibility area can be distinct in the model even when the first implementation has not yet created a separate deployable service.
- One Vocabulary Across Evidence Requirements, diagrams, protobuf contracts, logs, tests and operational evidence should use the same domain terms or document an intentional translation.
| Concern | Domain Model Owns | Documented Elsewhere |
|---|---|---|
| Responsibility | Business decisions, concepts and rules that naturally belong together. | Deployable service boundary, runtime ownership and scaling model. |
| Relationship | Conceptual meaning between Product, Basket, Order, Payment and Shipment. | RPCs, events, foreign keys, projections and network routes. |
| Lifecycle | Valid business states and transitions. | State persistence, concurrency control, retry mechanics and orchestration. |
| Vocabulary | Provider-neutral business terms and definitions. | Code package names, protobuf field names and provider-specific resources. |
Current Model And Evidence
The target domain model is broader than the current implementation. Catalog and Basket provide the first grounded responsibility areas. The remaining areas are modelled so that upcoming vertical slices have an explicit business shape without being described as implemented prematurely.
Catalog
Owns the governed product view, including Products, Variants, Categories, Attributes, commercial states and the product information used by discovery.
Implemented V1 Local SliceBasket
Owns mutable Basket state and Basket Items before purchase commitment, while validating referenced product and variant information with Catalog.
Implemented V1 Local SliceBrowse To Basket Collaboration
Provides the first evidence that separate responsibility areas can collaborate while preserving explicit ownership and validation.
Implemented And Smoke-TestedCheckout And Purchase Commitment
Will deepen the model around Checkout Attempt, Reservation, Payment Attempt, Order and compensation when the next vertical slice is designed and built.
PlannedFulfilment And Communication
Will define Shipment, Delivery Coordination and Notification responsibilities after the purchase-commitment model is stable.
PlannedInsight And Relevance
Search, Review and Recommendation concepts remain supporting responsibility areas that must not replace Catalog product truth.
PlannedRepository And Documentation Alignment
The
bfstore repository
contains implementation evidence, while this topic records the target conceptual
model. Current evidence for the first slice lives primarily in
services/catalog-service/
and
services/basket-service/.
Later repository tidy-up should align service documentation, contracts, tests and architecture records with the vocabulary and responsibility model established here. Older README wording, stale service lists or early workflow ordering should be treated as repo deviations rather than silently redefining the target model.
Continue Exploring
The next page begins with responsibility rather than entities: which business decisions belong together, which concepts each area governs and where ownership questions must be resolved before technical service boundaries are chosen.