Why The Story Matters
Borough Furniture Store is the fictional retailer behind bfstore. It gives the project a concrete business setting in which customers browse physical products, manage baskets, complete purchases and receive orders, while staff and external parties support the work behind those journeys.
The story matters because architecture needs a problem to solve. A generic collection of microservices can demonstrate tools, but it cannot explain why the boundaries exist, which failures matter or what correct behaviour means. Borough Furniture Store supplies that missing business gravity.
What The Story Must Do
The story must be specific enough to shape the domain while remaining broad enough for the application to grow in deliberate slices. It should establish the retailer, product range, customers, operating model and growth pressures without prescribing services, cloud products or deployment topology.
What The Story Must Not Do
The fictional company should not expand every time the project needs another technology demonstration. New actors, capabilities and workflows must earn their place through a clear business need and an explicit scope change.
Borough Furniture Store At A Glance
This snapshot records the current business scenario. It is a design baseline for the Business Context pages, not a claim that a live retailer or production commerce service exists.
Borough Furniture Store
The Fictional Retailer Behind bfstore
Story and scope defined
- Business Type
- Online retailer of developer-themed homeware
- Origin
- A small niche shop centred on Go and the Go gopher
- Product Direction
- Programming-language mascot and computer-science-inspired homeware
- Customer Market
- UK and EU customers within the current portfolio scenario
- Sales Channel
- Online commerce supported by the bfstore backend application
- Current Business Slice
- Product discovery and basket management Implemented locally
- Next Business Slice
- Checkout and the capabilities required to complete a purchase Planned
- Project Status
- Production-shaped portfolio system, not a live retailer Documented
The Business Story
Borough Furniture Store begins as a small specialist shop selling playful Go-themed homeware to Go enthusiasts. The name Borough is a deliberate play on burrow, the gopher's home, while giving the fictional retailer a distinctly British identity.
Early products include items such as gopher cushions, desk lamps, mugs and wall art. As the fictional retailer attracts more customers, the product range expands into other programming-language mascots and computer-science-inspired designs: tapestries, rugs, blankets, clocks, storage products and other homeware with developer-flavoured names and artwork.
This wider product range introduces realistic variation. A product may have multiple purchasable variants, category-specific attributes, images, prices and availability states. The memorable catalogue therefore supports serious modelling of product discovery, basket behaviour, inventory, checkout and fulfilment.
The Customer Promise
At its simplest, the business promises that customers can discover suitable products, understand what they are buying, place valid selections into a basket, complete a purchase and receive accurate information about the resulting order. Every later capability and workflow should support some part of that promise.
The Engineering Purpose
The company exists to make production-shaped engineering decisions explainable. Growth creates pressure around ownership, change, failure, observability, security and operation. Those pressures allow bfstore to evolve from a working commerce slice into a broader application, developer platform and cloud implementation without making technology the protagonist.
From Niche Shop To Growing Retailer
The growth narrative gives bfstore an ordered reason to introduce complexity. The system begins with the smallest useful customer journey and grows as the fictional retailer needs additional capabilities and stronger operational guarantees.
Borough Furniture Store Growth Narrative
Stage One: Prove Product Discovery And Basket Behaviour
The first useful slice allows a customer to browse the catalogue, select a valid product variant, create a basket and add that selection. This stage proves that two business responsibilities can collaborate while retaining explicit ownership.
Stage Two: Complete The Purchase Journey
Checkout introduces the need to coordinate product availability, payment, order creation and the start of fulfilment. It also creates business risks when individual steps succeed or fail at different times, such as stock being reserved without an order, repeated payment attempts or an accepted payment that cannot immediately progress to fulfilment.
Stage Three: Strengthen Operation And Change
As customer activity, application complexity and the engineering team grow, bfstore needs changes to remain safe and repeatable. The business also needs failures to be visible, access to be controlled and recovery to be dependable. The Platform, Cloud and Operations sections document the technical capabilities used to meet those expectations.
What The Project Models
bfstore models the backend behaviour needed to support a growing online retailer. It concentrates on the business and engineering boundaries that make ecommerce useful for platform, DevSecOps and cloud architecture practice.
- Products And Purchasable Variants. Customers browse a governed catalogue containing varied homeware products and the configurations available for purchase.
- Customer Basket Behaviour. Customers create and modify baskets before committing to a purchase.
- Commerce Completion. The application will coordinate availability, payment, orders and fulfilment as the checkout slice is implemented.
- Business Communication. Customers need accurate confirmation and status information as their purchase progresses.
- Production-Shaped Engineering. The project documents how the application is built, secured, observed, deployed, operated and recovered across cloud implementations.
Business Scope
The current scope is intentionally large enough to create meaningful engineering consequences, but smaller than the complete operating model of a real retailer. The table below records what the scenario currently includes and what remains deferred or outside the project's present boundary.
| Business area | Within the current scope | Deferred or outside the current scope |
|---|---|---|
| Sales channel | Online commerce supported by the bfstore backend. | Physical stores, marketplace selling and wholesale operations. |
| Customer market | A UK-based retailer serving UK and EU customers within the scenario. | Global tax, customs, localisation and international fulfilment models. |
| Product range | Physical developer-themed homeware with categories, variants, attributes, images and product states. | Manufacturing, product design, supplier procurement and warehouse purchasing. |
| Customer journey | Product discovery, basket management, checkout, order progress and customer communication. | A full customer relationship management platform or omnichannel experience. |
| Inventory and fulfilment | Stock availability, reservation and the hand-off needed to fulfil accepted orders. | Warehouse robotics, fleet management and carrier network optimisation. |
| Payments | Payment authorisation and the application boundary around completing a purchase. | Banking, settlement, accounting ledgers and a complete fraud platform. |
| Post-purchase | Order communication and later support for reviews and related customer interactions. | Returns, refunds, exchanges and customer support case management until explicitly added. |
| Organisation | Enough business roles and external parties to explain responsibilities, journeys and trust boundaries. | A complete company organisation design, HR model or financial operating plan. |
Scope Boundaries And Exclusions
Explicit exclusions stop bfstore from quietly becoming every possible ecommerce system at once. They also make portfolio claims more trustworthy because readers can distinguish deliberate focus from missing implementation.
- Business Need Before New Complexity A new service, integration or platform capability must answer an identifiable business or engineering requirement.
- Production-Shaped Rather Than Production The project models production responsibilities and controls, but it does not claim live customers, real payments or an operating retail company.
- Implemented, Designed And Planned Stay Distinct Documentation must identify whether a capability exists in code, has been designed or remains part of the future roadmap.
Explicit Current Exclusions
The present business story does not require physical retail locations, supplier management, manufacturing, warehouse automation, global logistics, complex accounting, a full CRM or a comprehensive returns platform. These areas can be introduced later only when they support a deliberate learning or architectural objective.
The Backend Boundary
bfstore primarily documents the backend application and the engineering system around it. Customer-facing interfaces may be represented where needed to explain a journey or contract, but building a complete storefront design system is not the current purpose of the project.
Assumptions And Constraints
Assumptions keep later pages from repeatedly inventing their own version of the business. They are working design inputs and should be revised when the scenario changes.
- The Retailer Is Fictional
- Names, customers, orders, payments and operational data are synthetic and exist for portfolio and learning purposes.
- The Products Are Physical Goods
- The domain must account for purchasable variants, stock and fulfilment rather than only digital delivery.
- The Scenario Begins In The UK And EU
- Regional needs should be made explicit when they affect the domain, without claiming complete legal or regulatory implementation.
- External Providers Remain Replaceable Boundaries
- Payment, delivery, identity and notification providers are business relationships before they become vendor-specific integrations.
- Growth Is Incremental
- The application is built in vertical slices so that new architecture is shaped by evidence from working behaviour.
- Correctness Matters More Than Feature Count
- Ownership, failure handling, traceability and operation are part of the product even when fewer customer features are implemented.
How Scope Shapes Engineering
Scope should leave fingerprints on the architecture. The table below shows how business choices create downstream design questions without prematurely selecting the technical answer.
| Business choice | Engineering consequence | Documented later in |
|---|---|---|
| Varied physical homeware | The domain needs products, purchasable variants, flexible category attributes and stock-aware behaviour. | Domain Concepts, Catalog Service, Inventory Service and Data & Persistence. |
| Online customer journey | The application must preserve behaviour across discovery, basket, checkout, order and fulfilment boundaries. | Customer Journeys, Application Workflows and Service Boundaries. |
| External payment and delivery relationships | The design needs explicit contracts, trust boundaries, failure handling and replaceable integration seams. | Actors & External Parties, Security & Trust, Resilience and Checkout Workflows. |
| Incremental growth | Capabilities are implemented as production-shaped vertical slices rather than creating every planned service at once. | Implementation Status, Service Dossiers, Testing Strategy and Project Evidence. |
| UK and EU scenario | Currency, customer data, regional behaviour and operational assumptions must be explicit where they affect the design. | Rules & Requirements, Security & Trust and provider-specific implementations. |
The Scope-To-Evidence Chain
- Business Story And Scope
- Actors And Capabilities
- Rules, Requirements And Journeys
- Architecture And Decisions
- Implementation
- Tests And Runtime Evidence
Repository And Evidence
This documentation is the source of truth for bfstore's intended business story and scope. The bfstore repository is the source of truth for the current implementation and its validation evidence. Where the two differ, the discrepancy is recorded and reconciled explicitly.
The repository README and supporting documents may still contain earlier terminology or workflow assumptions. Those differences should be tracked and reconciled against the agreed business story rather than copied into later documentation automatically.
The first implemented evidence for the business narrative lives in
services/catalog-service/
and
services/basket-service/.
Together they support the first business slice: discovering a purchasable product
and adding it to a basket.
Continue Exploring
With the retailer and its boundaries established, the next page identifies the people, internal roles and outside parties that participate in this business context.