Business & Domain

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.

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.

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.

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.

• Use Business Language FirstName concepts for what they mean to Borough Furniture Store before naming the technology that implements them.
• Keep Capabilities Separate From ServicesA capability may influence a service boundary, but it does not automatically justify one.
• Make Rules TestableImportant business invariants should be precise enough to become requirements, acceptance criteria and tests.
• Let Evidence Refine The ModelImplementation may expose missing concepts or poor boundaries; the domain model should evolve when the evidence is better.

Repository And Evidence

The public documentation describes the intended business model. The bfstore repository provides implementation evidence and may temporarily contain older v1 terminology or draft assumptions that will be reconciled as this section is completed.

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.

Continue Exploring

The Business & Domain index is the map. The next level separates business context, the domain model, rules and requirements, and customer journeys so that each can become detailed without mixing business meaning with implementation design.