bfstore

What Is bfstore?

bfstore is a production-shaped engineering project built around Borough Furniture Store, a fictional UK-based online retailer selling developer-themed homeware to customers across the UK and EU.

The retailer provides a stable business context for exploring a much broader engineering problem: how a business idea becomes software that can be built, deployed, secured, observed, operated and evolved. The aim is not to document cloud-native technologies in isolation. It is to show where they fit, why they were selected and how they help solve bfstore's requirements.

The project is organised into three connected layers: the application, the developer platform, and the cloud implementations. Architecture decisions, operational practice and implementation evidence cut across all three, allowing readers to move from a design claim to the artefacts that support it.

Project Snapshot

The snapshot below provides the quickest route into the project: what is being built, how the main layers relate to one another and which areas are currently implemented, in progress or planned.

The Business Story

Borough Furniture Store begins as a small fictional retailer with a playful product range and a comparatively simple application. As the business grows, the scenario introduces more customers, a larger engineering team, a broader product roadmap and greater expectations around availability, delivery and change.

Those pressures provide the reason for the engineering work. Service boundaries, asynchronous workflows, platform capabilities, cloud governance and operational controls are introduced in response to concrete business and engineering needs, rather than because a particular technology belongs on a cloud-native checklist.

The deeper business context, domain model, rules, requirements and customer journeys are documented in the Business & Domain area of the application documentation.

The Engineering Challenge

bfstore is deliberately large enough for decisions in one part of the system to create consequences elsewhere. A checkout request is not only application code: it crosses service contracts, data ownership, failure handling, telemetry, workload identity, deployment, networking, infrastructure policy and recovery.

The useful question is therefore not simply whether an individual feature or tool can be made to work. It is whether a business capability has the application, platform and cloud foundations required to behave predictably when the surrounding system is under change or failure.

Design Principles

A small set of principles keeps the project coherent as the application, developer platform and cloud implementations grow independently.

• Begin with business behaviour. Customer journeys, domain rules and requirements come before infrastructure products.
• Keep ownership explicit. Services own their responsibilities and data; platform and cloud boundaries have named purposes.
• Make contracts visible. APIs, events, infrastructure interfaces and policies should be reviewable and testable.
• Prefer evidence to architecture theatre. Designs link to implementation, validation, operational artefacts and known limitations.
• Use each cloud natively. AWS, Azure and Google Cloud solve the same bfstore requirements using their own governance, identity, networking and service models rather than forced one-to-one mappings.
• Keep it boring where production matters. Clarity, recoverability and operability win over novelty when a simpler choice does the job.

Significant choices and their trade-offs are recorded in the Architecture Decisions library. This keeps the reasoning visible without repeating the same decision history across multiple implementation pages.

From Business Idea To Running System

Readers can move through bfstore in roughly the same order as the engineering work itself: from business behaviour, through software design and developer enablement, to cloud implementation and operational proof.

1. Business Idea And Requirements. Define what Borough Furniture Store does, who interacts with it and the rules the system must preserve.
2. Application. Turn those capabilities into services, contracts, data boundaries, events and end-to-end workflows.
3. Developer Platform. Provide repeatable ways to build, test, provision, deploy, observe and operate those services.
4. Cloud Implementations. Realise the requirements using provider-native organisation, identity, governance, networking, security, runtime and data services.
5. Operate And Prove It. Use SLOs, runbooks, tests, experiments, recovery exercises and repository evidence to validate the design.

Explore bfstore

This overview is intentionally brief. Each area below opens a deeper part of the project while keeping the business context attached to the engineering work.

A Customer Journey Through The Architecture

Customer journeys provide the bridge between the fictional business and the distributed system. Checkout is especially useful because one customer action crosses several service and operational boundaries.

1. Browse the product catalogue.
2. Add one or more products to a basket.
3. Begin checkout.
4. Validate and reserve inventory.
5. Authorise payment.
6. Create the order.
7. Trigger fulfilment and customer notification.

The workflow documentation follows these journeys across synchronous calls, resulting events, data changes, telemetry and failure paths, showing how apparently simple business actions become end-to-end system behaviour.

Implementation Status

bfstore is built in slices, and the documentation distinguishes implemented behaviour from designs that are still being validated or planned. This makes the project useful as a record of engineering progress rather than a description of an imagined finished state.

Detailed progress, validation results and future work are maintained in the implementation status and roadmap pages.

Project Evidence

A design claim becomes more useful when it can be traced to something concrete. Where a bfstore design has been implemented, the documentation links onwards to the repository, code, tests and operational artefacts that demonstrate it.

The project currently spans several repositories with deliberately different responsibilities:

• bfstore — application services, contracts, domain code, persistence and application tests.
• bfstore-developer-platform — developer-facing platform capabilities, standards and self-service experience.
• bfstore-platform-infra — cloud and platform infrastructure composition.
• bfstore-iac-modules — reusable OpenTofu-first infrastructure modules.
• bfstore-platform-gitops — declarative workload and platform delivery through GitOps.
• bfstore-security-governance — security, governance, policy and validation artefacts.

Roadmap

The roadmap follows the project's dependency chain. Later layers are intended to be shaped by evidence from earlier implementation work rather than designed entirely in the abstract.

1. Deepen the application. Continue implementing the core business journeys, service contracts, persistence, events, failure handling and telemetry.
2. Complete the AWS foundation. Turn the organisation, identity, governance, networking and IPAM designs into tested infrastructure and reusable OpenTofu modules.
3. Build the developer platform. Bring the delivery, GitOps, Kubernetes, self-service, policy, secrets and observability capabilities together into coherent developer golden paths.
4. Implement bfstore natively on Azure, then Google Cloud. Preserve the business and platform requirements while allowing each provider's own architecture to shape the implementation.
5. Build the separate multi-cloud capstone. After the three single-cloud implementations exist, explore what should genuinely be abstracted and what should remain provider-native.

As implementation produces better evidence, the project documentation records that evolution: what was required, what was chosen, what was built, what failed, what was learned and what changed next.