Cloud Sandbox

bfstore · Domain Model

Domain Areas & Responsibilities

The business responsibility areas within Borough Furniture Store, the decisions and concepts each area governs, and the ownership questions that later shape service boundaries.

Last updated:

Why Responsibility Comes First

Borough Furniture Store needs clear ownership of business decisions. Someone must decide which Products and Variants are valid for sale, what belongs in a Basket, whether stock can be reserved, what a Payment outcome means and when an Order has been accepted. If these decisions have no clear home, the application accumulates shared ownership, duplicated rules and contradictory sources of truth.

Domain Areas provide that home in the problem space. They identify coherent responsibilities without assuming that every responsibility deserves an independent microservice. Later architecture can evaluate coupling, change, scaling, failure isolation and operational cost before assigning technical boundaries.

Domain Area A coherent area of business responsibility with its own decisions, concepts, rules and language.
Responsibility A business decision or obligation that must have one accountable home, even when several areas collaborate in the outcome.
Source Of Truth The authoritative business record or decision for a concept. Projections and collaborators may copy or reference it without becoming its owner.

The Question This Page Answers

Which business decisions and concepts belong together, and where must ownership be explicit before bfstore chooses service boundaries, contracts, data stores and workflows?

Responsibilities At A Glance

The Domain Responsibility Map

The map groups responsibility areas around the purchase lifecycle. Green marks the areas grounded by the first working slice, gold marks cross-area coordination, blue marks supporting projections or experience responsibilities and violet marks target areas that remain planned.

Implemented V1 Local Slice Supporting Or Partial Responsibility Cross-Area Coordination Planned Responsibility Area

Borough Furniture Store Domain Responsibility Map

A domain responsibility map showing Catalog and Basket as implemented areas, Checkout as a coordination responsibility, Inventory, Payment, Order, Fulfilment and Notification as planned areas, and Search, Review and Recommendation as supporting areas. Arrows show business collaboration rather than service calls.
The responsibility map follows the purchase lifecycle while keeping sources of truth distinct. Checkout coordinates Inventory, Payment and Order outcomes; supporting Search, Review and Recommendation areas do not replace Catalog truth.

Responsibility Classification

Not every area plays the same role. Classifying responsibilities helps later architecture avoid treating transactional truth, coordination and derived experience data as interchangeable.

Domain Responsibility Classes
Class Purpose Areas Ownership Characteristic
Authoritative Commerce Responsibility Own a durable business decision or record needed to complete and fulfil a purchase. Catalog, Basket, Inventory, Payment, Order And Fulfilment Must have an explicit source of truth and invariant owner.
Coordination Responsibility Coordinate outcomes across several authoritative areas for a customer journey. Checkout Owns coordination state and idempotency where required, not every participating area's record.
Communication Responsibility Turn significant business outcomes into controlled customer messages. Notification Owns notification intent and delivery state, not the Order or Payment outcome being communicated.
Supporting Experience Responsibility Improve discovery, relevance and trust using governed inputs. Search, Review And Recommendation May own projections or feedback but must not replace Catalog or Order truth.

Core Commerce Areas

These areas own the durable decisions and records that move a customer from product discovery to an accepted and fulfilled purchase.

Catalog

Governs the retailer's product truth and the commercial information needed to understand purchasable items.

Owns Decisions About
Products, Categories, Variants, Attributes, Images, product state and the initial catalog price.
Does Not Own
Basket state, stock reservations, Orders, Payments, Shipments, Reviews, Recommendations or search projections.
Important Collaborations
Basket validation, Search projection, Recommendation inputs and Product Discovery.
Implemented V1 Local Slice

Basket

Governs the customer's mutable pre-purchase selection before an accepted Order exists.

Owns Decisions About
Basket identity, Basket status, Basket Items, quantities and valid mutations.
Does Not Own
Product truth, stock allocation, payment outcome or the accepted Order record.
Important Collaborations
Catalog product and variant validation, Checkout initiation and customer journeys.
Implemented V1 Local Slice

Inventory

Governs stock availability and the controlled allocation of stock to purchase attempts or accepted Orders.

Owns Decisions About
Available quantity, Reservation state, allocation, release and stock adjustment.
Does Not Own
Product descriptions, Basket Items, Payment state or the Order lifecycle.
Important Collaborations
Checkout, Order, Fulfilment and operational reconciliation.
Planned

Payment

Governs bfstore's record of payment attempts and the meaning of provider outcomes around purchase commitment.

Owns Decisions About
Payment Attempt identity, status, idempotency, provider reference and recognised outcome.
Does Not Own
The provider's internal ledger, Basket contents, stock or the accepted Order record.
Important Collaborations
Checkout, Order, Finance And Operations Staff and the Payment Provider.
Planned

Order

Governs the retailer's authoritative record of an accepted purchase and its business lifecycle.

Owns Decisions About
Order identity, Order Items, committed commercial snapshot, status and accepted-purchase history.
Does Not Own
Current Product truth, provider payment internals or Shipment delivery state.
Important Collaborations
Checkout, Inventory, Payment, Fulfilment, Notification and Customer Support.
Planned

Fulfilment

Governs the work required to move an accepted Order toward dispatch and delivery.

Owns Decisions About
Shipment identity, fulfilment status, dispatch, carrier hand-off and delivery references.
Does Not Own
The accepted Order record, Product truth or customer-message delivery state.
Important Collaborations
Order, Inventory, Delivery Provider, Fulfilment Staff and Notification.
Planned

Notification

Governs customer-message intent and delivery state for significant business outcomes.

Owns Decisions About
Notification identity, channel, template reference, delivery status, retry and suppression state.
Does Not Own
The Order, Payment or Shipment outcome described by the message.
Important Collaborations
Order, Fulfilment, Customer Support and the Notification Provider.
Planned

Supporting Experience Areas

Supporting areas improve how customers discover, evaluate and understand products. They may own specialised data or projections, but their usefulness depends on authoritative commerce areas remaining clear.

Search

Owns denormalised search projections, indexing state and relevance-oriented representations derived from governed Catalog information.

Source Of Truth Rule
Search can optimise discovery but cannot redefine Products, Variants, Categories or sale state.
Important Collaborations
Catalog, Product Discovery and operational projection recovery.
Planned

Review

Owns supported customer feedback, moderation state and the rules governing whether feedback may be displayed.

Source Of Truth Rule
Review owns feedback content, not Product definition or Order truth.
Important Collaborations
Customer, Catalog references, Order evidence and Customer Support.
Planned

Recommendation

Owns recommendation outputs, model or ruleset versions and the evidence needed to explain supported suggestion behaviour.

Source Of Truth Rule
Recommendations suggest Products but cannot make an unavailable or inactive Variant purchasable.
Important Collaborations
Catalog, Search, customer-behaviour inputs and Product Discovery.
Planned

Coordination Across Areas

Some customer outcomes require several responsibility areas to agree. Checkout is the clearest example: a Basket must be suitable for purchase, stock must be available, payment must reach an acceptable outcome and an Order must be committed. Coordination makes those outcomes work together without becoming their shared owner.

Checkout Coordination

Coordinates the transition from mutable Basket state to a committed purchase.

May Own
Checkout Attempt identity, workflow progress, idempotency state and compensation decisions required to complete the journey safely.
Must Not Absorb
Catalog truth, Inventory quantities, Payment records, Order truth or Shipment state.
Later Architecture Decision
The technical home of coordination, including the planned role of Order in orchestration, belongs under Application Architecture and the Checkout workflow.
Planned Coordination Responsibility
  1. Basket Selection
  2. Checkout Attempt
  3. Inventory Outcome
  4. Payment Outcome
  5. Order Commitment
  6. Fulfilment Handoff

Ownership Rules

Authoritative Ownership Across Domain Areas
Business Concept Or Decision Authoritative Area Permitted Collaborators Ownership Guardrail
Product And Variant Definition Catalog Basket, Search, Review, Recommendation, Order Collaborators reference or snapshot product information; they do not redefine current Catalog truth.
Mutable Pre-Purchase Selection Basket Catalog And Checkout An Order is not created merely because a Basket exists.
Stock Availability And Reservation Inventory Checkout, Order And Fulfilment No other area decrements or promises stock independently.
Payment Attempt And Outcome Payment Checkout, Order, Finance And Payment Provider The provider contributes an outcome; bfstore owns its recognised Payment state.
Accepted Purchase Record Order Checkout, Payment, Inventory, Fulfilment, Notification And Support Order status changes follow Order rules rather than being rewritten by collaborators.
Shipment And Dispatch State Fulfilment Order, Delivery Provider, Notification And Support Carrier updates are inputs to Fulfilment state, not direct mutations of Order truth.
Notification Delivery State Notification Order, Fulfilment, Support And Notification Provider Message delivery status does not change the business outcome being communicated.
Search Representation Search Catalog And Product Discovery Search owns its projection and recovery, not the governed Product record.
  • One Accountable Decision Owner Several areas may participate in an outcome, but each authoritative business decision must have one clear home.
  • References Do Not Transfer Ownership Holding an identifier, snapshot or projection does not make a collaborating area the source of truth.
  • Coordination Must Preserve Boundaries Workflow orchestration should combine outcomes rather than duplicate the rules and persistence of every participant.

From Domain Areas To Service Boundaries

Domain Areas are strong inputs to service-boundary design, but the mapping is not mechanical. Architecture must decide whether a responsibility needs a distinct deployment unit and whether the operational cost of separation is justified.

Questions Used To Translate Responsibility Into Architecture
Architecture Question Why It Matters Possible Outcome
Is The Business Responsibility Cohesive? Concepts and rules that change together may deserve one ownership boundary. Keep together until evidence shows a meaningful split.
Does The Area Need Independent Data Ownership? Authoritative decisions require controlled persistence and mutation. Separate schema or service-owned database when technically assigned.
Does It Change Or Scale Differently? Distinct change cadence or workload may justify independent deployment. Separate service, worker, projection or deployment profile.
Does Failure Need Isolation? A supporting capability should not unnecessarily take down purchase commitment. Asynchronous boundary, projection or independently recoverable component.
Is The Operational Cost Justified? Every service introduces deployment, security, observability and recovery work. Retain a modular boundary without immediately creating another service.
Who Can Own And Operate It? Technical boundaries need accountable maintainers and operational evidence. Align service ownership after business responsibility is understood.
  1. Business Capability
  2. Domain Decisions
  3. Responsibility Area
  4. Ownership Boundary
  5. Architecture Trade-Offs
  6. Service Boundary
  7. Runtime Evidence

Repository And Evidence

The bfstore repository provides current implementation evidence. Catalog is explicitly documented as the owner of product catalog information and excludes Basket, Inventory, Order, Payment, Shipping, Notification, Review, Recommendation and Search responsibilities. That separation is useful evidence for the responsibility model established here.

The first working slice also gives Basket its own mutable state while using Catalog validation for referenced products and variants. The remaining areas on this page are target responsibilities and must remain marked as planned until their contracts, code, persistence, tests and runtime evidence exist.

Continue Exploring

With responsibility areas established, the next page defines the business concepts those areas govern and the relationships between Products, Variants, Baskets, Reservations, Orders, Payments and Shipments.

Domain Model Domain Concepts & Relationships Business & Domain Index