Why Participants Matter
Borough Furniture Store exists within a network of people and organisations. Customers discover products and place orders. Internal roles maintain product information, support customers, fulfil accepted purchases and oversee commercial activity. External parties may authorise payments, carry parcels, deliver notifications or provide customer identity services.
Identifying those participants before designing the application makes later decisions easier to explain. Customer journeys gain named participants, requirements gain accountable beneficiaries, security work gains meaningful trust boundaries and integrations gain a clear business purpose.
What This Page Establishes
This page records the current participant model, the goals associated with each participant and the business boundaries that later pages must preserve. It does not yet define detailed permissions, provider contracts, service accounts or failure-handling mechanisms.
Participation At A Glance
The Business Interaction Map
The interaction map places Borough Furniture Store between the people operating the business and the outside parties that support customer outcomes. Solid green emphasis marks the first working customer interaction. Violet provider relationships remain planned business boundaries until their integrations are selected and implemented.
Borough Furniture Store Actor Ecosystem
The Primary Customer Actor
The customer is the primary beneficiary of the commerce journey. Within the current scope, the customer is a person in the UK or EU seeking physical developer-themed homeware through the online sales channel.
| Customer Goal | Expected Business Outcome | Related Capability | Current Status |
|---|---|---|---|
| Discover Suitable Products | Browse accurate product, variant and availability information. | Product Discovery | Implemented V1 Local Slice |
| Keep A Purchase Selection | Create a basket and add, update or remove valid selections. | Basket Management | Implemented V1 Local Slice |
| Complete A Purchase | Confirm the basket, provide required details and receive a committed order outcome. | Checkout, Payment And Order Management | Planned |
| Understand Order Progress | Receive accurate confirmation and fulfilment information. | Order Management, Fulfilment And Customer Communication | Planned |
| Interact After Purchase | Use supported post-purchase features without the project claiming a complete returns or support platform. | Reviews And Post-Purchase Experience | Planned |
Customer Identity Is A Separate Decision
The customer actor exists whether the first interaction is anonymous, session based or associated with an authenticated account. The identity model must later explain when the application needs to recognise the same customer, which data is retained and how access is protected. This page does not pre-select that model.
Internal Business Actors
Internal actors represent business responsibilities rather than a final company organisation chart. A small retailer may combine several responsibilities within one person, while a larger retailer may divide them across teams. The domain should preserve the responsibility even when the organisational shape changes.
Merchandising And Catalog Staff
Maintain the commercial product view presented to customers.
- Primary Goals
- Keep products, variants, categories, attributes, prices, images and sale states accurate.
- Depends Upon
- Product Management and Product Discovery capabilities.
- Boundary Note
- This actor does not automatically own inventory quantities or application deployment.
Customer Support Staff
Help customers understand orders and resolve supported commerce problems.
- Primary Goals
- Find reliable customer and order information, explain status and initiate permitted support actions.
- Depends Upon
- Order Management, Customer Communication and later Post-Purchase capabilities.
- Boundary Note
- Support access must later be limited to the information and actions required by the role.
Fulfilment Staff
Prepare accepted orders for shipment and maintain accurate fulfilment progress.
- Primary Goals
- Receive fulfilment work, prepare items, hand parcels to a carrier and record progress.
- Depends Upon
- Inventory, Order Management and Fulfilment capabilities.
- Boundary Note
- Warehouse automation and fleet management remain outside the current scope.
Finance And Operations Staff
Oversee the commercial and operational state needed to run the modelled retailer.
- Primary Goals
- Review payment and order outcomes, investigate exceptions and understand business operation.
- Depends Upon
- Payment, Order Management, reporting and operational evidence.
- Boundary Note
- bfstore does not currently model a complete accounting ledger or enterprise resource planning system.
External Parties
External parties provide capabilities or business outcomes that Borough Furniture Store does not model as part of its own core commerce domain. They should remain replaceable boundaries until a deliberate provider decision is recorded.
Payment Provider
Authorises customer payment attempts and returns a business outcome the checkout flow can use.
- Business Dependency
- A purchase cannot be confirmed without the required payment outcome.
- Later Design Concerns
- Idempotency, sensitive data boundaries, timeouts, declines, retries and reconciliation.
Delivery Provider
Accepts shipment work and carries a parcel toward the customer.
- Business Dependency
- Fulfilment requires a reliable hand-off and understandable delivery progress.
- Later Design Concerns
- Shipment references, status updates, duplicate callbacks, unavailable carriers and evidence.
Notification Provider
Delivers supported customer messages through channels selected by later design.
- Business Dependency
- Customers need timely and accurate information about important order outcomes.
- Later Design Concerns
- Channel choice, delivery failure, retries, templates, preferences and duplicate suppression.
Customer Identity Provider
May authenticate customers when a journey requires a persistent customer identity.
- Business Dependency
- Some future journeys may need secure account access and continuity across sessions.
- Later Design Concerns
- Federation, account lifecycle, consent, recovery, privacy and separation from workforce identity.
External Parties Are Not Core Domain Owners
A provider may perform an important action without owning Borough Furniture Store's business record. For example, a payment provider can authorise a payment attempt while bfstore still owns its payment state and the order outcome derived from it. The exact ownership model is documented later.
The Interaction Catalogue
The catalogue provides one traceable view of each participant, the outcome they need and the part of the business model that supports it. Status describes the current bfstore implementation, not the importance of the participant.
| Participant | Type | Primary Business Interaction | Related Capabilities | Status |
|---|---|---|---|---|
| Customer | External Human Actor | Discover products, maintain a basket, complete a purchase and follow the order. | Discovery, Basket, Checkout, Order, Fulfilment And Communication | Discovery And Basket Implemented; Remaining Journey Planned |
| Merchandising And Catalog Staff | Internal Business Actor | Maintain the commercial product information shown to customers. | Product Management And Discovery | Business Responsibility Defined; Staff Workflow Planned |
| Customer Support Staff | Internal Business Actor | Understand customer and order state and perform permitted support actions. | Order, Communication And Post-Purchase | Planned |
| Fulfilment Staff | Internal Business Actor | Prepare accepted orders, hand parcels to carriers and record progress. | Inventory, Order And Fulfilment | Planned |
| Finance And Operations Staff | Internal Business Actor | Review commercial outcomes, exceptions and operational state. | Payment, Order And Operational Evidence | Planned |
| Payment Provider | External Organisation | Return an authorisation outcome for a payment attempt. | Payment And Checkout | Planned |
| Delivery Provider | External Organisation | Accept shipment work and return delivery progress. | Fulfilment And Customer Communication | Planned |
| Notification Provider | External Organisation | Deliver supported customer messages. | Customer Communication | Planned |
| Customer Identity Provider | External Organisation | Authenticate customers for journeys requiring persistent identity. | Customer Access And Account Continuity | Planned; Identity Model Undecided |
Trust And Responsibility Boundaries
Participants introduce boundaries that the later application must make explicit. The business view identifies why the boundary exists; Security, Communication, Resilience and service dossiers later define the technical controls.
- Human To Business Boundary Customers and staff require controlled ways to request actions and view data. The eventual identity and permission model must follow the actor's business need.
- Retailer To Provider Boundary External providers operate outside bfstore's direct control. Contracts, timeout behaviour, retries, audit evidence and replacement strategy must be explicit.
- Responsibility To Ownership Boundary Participating in an outcome does not automatically grant ownership of the retailer's business record, source of truth or final decision.
| Boundary Question | Business Meaning | Documented Later In |
|---|---|---|
| Who May Request The Action? | The actor's goal determines whether the interaction is appropriate. | Customer Journeys, Functional Requirements And Security & Trust |
| Which Information May Cross The Boundary? | Only the information necessary for the business outcome should be shared. | Communication & Contracts, Data & Persistence And Privacy Requirements |
| Who Owns The Business Record? | A provider can contribute an outcome without becoming the retailer's source of truth. | Service Boundaries & Ownership And Service Dossiers |
| What Happens When A Participant Is Unavailable? | The customer promise must remain understandable when a provider or staff workflow cannot proceed. | Resilience & Failure Handling And Application Workflows |
| What Evidence Must Be Retained? | The business needs enough evidence to explain significant decisions and outcomes. | Observability, Testing Strategy, Operations And Evidence |
How Participants Shape Later Design
Participants become useful architectural inputs through traceability. Their goals shape journeys and requirements; their boundaries shape security, contracts, ownership and failure handling.
- Participant
- Business Goal
- Customer Or Staff Journey
- Requirement
- Trust Boundary
- Application Interaction
- Evidence
Goals Shape Journeys
A customer trying to complete a purchase and a fulfilment worker trying to prepare an accepted order participate in different journeys, even when those journeys touch the same order.
Responsibilities Shape Access
A participant should receive the information and actions needed for their responsibility, not broad access merely because they are inside the organisation or integrated with the application.
External Dependencies Shape Failure Handling
A provider relationship introduces latency, failure, contractual and evidence concerns. Those concerns exist because of the business dependency, not because a particular SDK or protocol was selected.
Repository And Evidence
The
bfstore repository
currently provides implementation evidence for the first customer interaction:
product discovery and basket management. That evidence lives primarily in
services/catalog-service/
and
services/basket-service/.
Staff-facing workflows and integrations with payment, delivery, notification and customer identity providers remain target business relationships rather than completed repository evidence. Later repo tidy-up should preserve that distinction and avoid presenting a planned service name as proof of an implemented actor journey.
Continue Exploring
With the participants and boundaries identified, the next page defines the capabilities Borough Furniture Store must possess to support their goals.