Why Start With The Business?
Borough Furniture Store is useful as an engineering project because it begins with a business that has goals, customers, responsibilities and rules. The application should be shaped by those needs rather than by a list of technologies that happen to be interesting to deploy.
This collection therefore establishes the business meaning that the rest of the application must preserve. It explains what the retailer needs to be capable of doing, which concepts matter, what must always remain true and how customers move through the business before those ideas are translated into service boundaries, contracts, data models and workflows.
The Role Of This Collection
Business & Domain provides the vocabulary and constraints used by later design work. A service dossier should be able to point back to the capability it owns, a workflow should be able to point back to the customer journey it implements, and a test should be able to point back to the rule or requirement it proves.
Scope Boundary
The boundary is deliberately simple: this section explains what the business means and requires. Application Architecture begins when bfstore decides how the software should satisfy those requirements.
Business & Domain At A Glance
The section is organised as a progression from context to behaviour. Readers can start with the fictional retailer, move through its concepts and invariants, then follow those rules into requirements and customer journeys that later shape the application design.
bfstore business & domain
Define The Problem Before Designing The Software
Structure agreed · content in progress
- Starts With
- Borough Furniture Store as a fictional UK-based ecommerce business serving customers across the UK and EU
- Business Context
- Scope, actors, external parties and the capabilities the retailer needs
- Domain Model
- Responsibility areas, concepts, relationships, lifecycles and shared vocabulary
- Rules & Requirements
- Business invariants, functional behaviour, quality requirements and traceability
- Customer Journeys
- Business-facing flows from product discovery through basket, checkout and fulfilment
- Ends At
- The hand-off into Application Architecture, where technical boundaries and contracts are chosen
- Current Grounding
- Catalog + Basket provide the first implemented slice against which the domain model can be tested
- Primary Evidence
- Business context, domain definitions, rules, requirements and journey descriptions, with links to contracts, implementation and tests where those artefacts currently exist
Explore Business & Domain
Four topic areas divide the collection by the question a reader is trying to answer. Each topic has its own index page and then a small number of focused standalone documents beneath it.
The Borough Furniture Store story, scope, actors, external parties and business capabilities that create the need for the application.
02 · Domain ModelWhat Concepts And Responsibilities Exist?Domain areas, business concepts, relationships, lifecycles and vocabulary without prematurely turning them into microservices or database tables.
03 · Rules and RequirementsWhat Must bfstore Do And Preserve?Business rules, invariants, functional and quality requirements, plus the traceability that connects them to implementation evidence.
04 · Customer JourneysWhat Is The Customer Trying To Accomplish?Business-facing journeys through product discovery, basket management, checkout, fulfilment and later post-purchase experiences.
From Business Intent To Application Design
The domain material is not an isolated requirements exercise. Its purpose is to give later architecture decisions something concrete to satisfy. A capability gives the system a reason to exist; rules constrain correct behaviour; requirements make that behaviour testable; customer journeys combine it into outcomes that the application must deliver.
From Business Intent To Application Design
Problem Space Before Solution Space
A business capability is not automatically a service. A domain concept is not automatically a database table. A customer journey is not automatically a chain of RPC calls. Those mappings are architectural choices and should remain open until the business responsibilities are understood clearly enough to make them.
What Changes At The Architecture Boundary
The hand-off occurs when bfstore begins assigning technical ownership. Domain responsibilities inform service candidates; requirements become contracts and acceptance criteria; business lifecycles influence state models; journeys become cross-service workflows. Those decisions belong in Application Architecture and should link back to the business material that justified them.
How The First Slice Maps Back To The Business
Catalog and Basket give the domain documentation a real implementation boundary to test against. The first vertical slice is useful because it already connects a customer-facing need to business concepts, ownership and executable behaviour.
| Business Intent | Domain Meaning | Current Implementation Evidence |
|---|---|---|
| Customers can discover products they may want to buy. | Product, Variant, Category and sellability are concepts within the product-discovery domain. | Catalog service owns the current product read model and product/variant validation behaviour. |
| Customers can maintain an intended purchase before checkout. | A Basket owns mutable pre-checkout state containing one or more Basket Items. | Basket service owns basket lifecycle and item operations with its own persistence boundary. |
| A Basket must not accept a product selection that is invalid or unavailable for sale. | Basket behaviour depends on the selected Product and Variant being valid and sellable, without taking ownership of product truth. | Basket validates the selection through Catalog before persisting it, preserving the responsibility boundary between the two domains. |
| The first customer journey should be repeatable and verifiable. | Product discovery and basket management form one Customer Journey rather than two unrelated features. | Browse To Basket smoke flow exercises the implemented cross-service journey locally. |
Traceability Is Two-Way
Implementation is evidence, not merely an endpoint. If building Basket reveals that a domain concept is poorly named, a business rule is incomplete or ownership is ambiguous, the domain documentation should be corrected. The website and repository should converge on the same model as bfstore matures.
Keeping The Boundary Clean
The easiest way for this collection to become muddy is to mix business meaning with implementation detail. The table below sets the editorial boundary we will use throughout the Business & Domain pages.
| Concern | Business & Domain Position | Where Technical Detail Belongs |
|---|---|---|
| Business capability | Define what Borough Furniture Store needs to be capable of doing. | Application Architecture decides whether and how that capability becomes one or more technical boundaries. |
| Business rule | State the invariant in implementation-neutral language. | Services and workflows describe where and how the rule is enforced. |
| Customer journey | Describe the outcome and business steps from the customer perspective. | Application Workflows describe RPCs, events, state changes, failure paths and compensation. |
| Domain concept | Define its business meaning, relationships and lifecycle. | Data & Persistence describes schemas, storage models, migrations and projections. |
| Quality expectation | Record the required property and why the business needs it. | Architecture, Operations and Cloud document the mechanisms, targets and operational controls used to satisfy it. |
- Use Business Language First Name concepts for what they mean to Borough Furniture Store before naming the technology that implements them.
- Keep Capabilities Separate From Services A capability may influence a service boundary, but it does not automatically justify one.
- Make Rules Testable Important business invariants should be precise enough to become requirements, acceptance criteria and tests.
- Let Evidence Refine The Model Implementation may expose missing concepts or poor boundaries; the domain model should evolve when the evidence is better.
Repository And Evidence
The documentation is the source of truth for bfstore's intended business and domain model. The bfstore repository is the source of truth for the current implementation and its validation evidence. Where they differ temporarily, the discrepancy should be recorded and reconciled explicitly.
From Business Meaning To Evidence
The goal is not to produce a requirements archive that becomes detached from the code. Each important business concept should eventually have a visible path into the design and evidence that implement it.
- Business Context
- Capability Or Journey
- Business Rule
- Requirement
- Architecture Or ADR
- Implementation
- Test Or Evidence
Continue Exploring
The Business & Domain collection provides the shared language and constraints for the rest of the application documentation. Its concepts, rules, requirements and journeys should remain visible as bfstore moves into architecture and implementation.
Begin with Business Context to understand the retailer, its actors and the capabilities the application must support. From there, continue into the domain model, explicit requirements and customer journeys.