Why Business Context Comes First
Borough Furniture Store should be understandable as a business before it is presented as a software architecture. Customers do not arrive asking for gRPC, Kafka or Kubernetes. They arrive to discover products, keep a basket, complete a purchase and receive what they ordered. Staff and external parties have their own responsibilities around products, payments, fulfilment and customer communication.
Business Context gives those needs a stable home. It defines the fictional retailer being modelled, the boundaries of the project, the people and organisations that interact with it and the capabilities the business must possess. Later pages can then make technical decisions against an explicit business setting rather than an accidental collection of tools.
The Role Of This Topic
This topic establishes the inputs needed by the rest of Business & Domain. The Domain Model uses the capabilities and responsibilities identified here. Rules & Requirements make the expected behaviour testable. Customer Journeys describe how actors use those capabilities to achieve useful outcomes.
The Boundary With Later Design
Business Context can say that the retailer must manage baskets, take payments and fulfil orders. It should not conclude that each capability requires a separate service, choose a payment integration or define the sequence of RPCs used during checkout. Those are downstream design decisions.
Business Context At A Glance
The index is organised around three complementary views. Together they explain what Borough Furniture Store is, who participates in its operation and what the business must be capable of doing.
bfstore business context
The Setting Around The Software
Index complete · child pages in progress
- Business Setting
- A fictional UK-based ecommerce retailer selling developer-themed homeware to customers across the UK and EU
- Market
- Customers in the UK and EU within the current portfolio scenario
- Establishes
- Story, scope, actors, external parties, capabilities, assumptions and exclusions
- Feeds Into
- Domain modelling, rules, requirements, customer journeys and application architecture
- Does Not Decide
- Service boundaries, protocols, schemas, deployment topology or provider services
- Current Evidence
- Product discovery and basket management form the first implemented local business slice Implemented
- Documentation Status
- Index structure and content complete; three child pages remain in progress In progress
- Source Repository
- mantrobuslawal/bfstore
Explore Business Context
Each child page owns one clear question. Keeping them separate gives the business story, participants and capability map enough room to evolve without turning this index into a long-form catch-all.
Establish Borough Furniture Store's commercial story, market, growth pressures, project boundaries, assumptions and explicit exclusions.
Actors And External PartiesIdentify Who ParticipatesDescribe customers, internal business roles and outside organisations or systems that interact with the retailer.
Business CapabilitiesDescribe What The Business Must Be Able To DoMap the capabilities needed to discover products, manage commerce, fulfil orders and support customers without turning capabilities into services prematurely.
The Business Context Map
A business context map places Borough Furniture Store at the centre of its operating environment. It shows who interacts with the business, which outside relationships may be required and the capabilities the retailer must coordinate. It deliberately stops before technical integration and deployment details.
Borough Furniture Store Business Context
What Business Context Establishes
The three child pages work together. One provides the operating story, one identifies the participants around it and one describes the outcomes the business must be able to produce.
| Business question | Business Context establishes | Used later by |
|---|---|---|
| What business are we modelling? | The retailer's purpose, market, commercial story, assumptions, boundaries and exclusions. | Domain scope, requirements, roadmap decisions and the limits of the portfolio narrative. |
| Who interacts with it? | Customers, internal business roles and external parties with distinct goals and responsibilities. | Customer journeys, access decisions, trust boundaries, integration requirements and operational ownership. |
| What must the business be able to do? | Capabilities such as product discovery, basket management, inventory, checkout, payment and fulfilment. | Domain responsibility areas, service-boundary analysis, workflows, prioritisation and implementation slices. |
| What is excluded or deferred? | Explicit limits that prevent the fictional business from expanding silently whenever a new technology is interesting. | Architecture constraints, implementation status, roadmap sequencing and honest portfolio claims. |
Capabilities Are Not Services
A business capability describes an outcome the organisation must be able to achieve. It does not prescribe a deployable component. Product Discovery may involve Catalog, Search and Recommendation behaviour; Customer Communication may involve several workflows. Service boundaries are chosen later, using domain responsibilities, coupling, ownership and operational trade-offs.
Actors Are Not Authentication Roles
An actor represents a person, team or external party participating in the business. The later security model may translate those actors into identities, permissions and policies, but Business Context should not begin with IAM groups, tokens or cloud roles.
How Context Shapes Later Design
Business Context becomes useful when later documentation can trace a design decision back to it. The context should not prescribe the answer, but it should make the reason for that answer visible.
- Story And Scope Constrain Complexity Architecture should solve the needs of the modelled retailer rather than grow because the project can technically support another component.
- Actors Reveal Interactions And Trust Knowing who performs an action helps later pages define journeys, ownership, authentication, authorisation and external dependencies.
- Capabilities Guide Responsibility Analysis Capabilities provide the business view that domain modelling and service-boundary design can refine without treating the organisation chart as deployment topology.
The Context-To-Design Chain
- Business Story
- Actors And External Parties
- Capabilities And Journeys
- Domain Model And Rules
- Requirements
- Application Architecture
The First Working Slice
The implemented Catalog and Basket slice can already be described without technical language: a customer discovers an active product and purchasable variant, creates a basket and adds that selection to it. Catalog and Basket are implementation choices beneath that behaviour. The business context gives the slice its meaning.
Repository And Evidence
This documentation is the source of truth for bfstore's intended business context. 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.
Corresponding business and domain records should be maintained beneath the
repository's
docs/
hierarchy as the documentation is reconciled with this structure. Current code
evidence for the first slice lives in
services/catalog-service/
and
services/basket-service/.
- Business Context
- Rule Or Requirement
- Architecture Or ADR
- Implementation
- Test Or Runtime Evidence
Continue Exploring
The next page should establish the fictional retailer and its boundaries in enough detail to support the actor catalogue and capability map without inventing technical structure too early.