Problem Domain and Scope

The problem domain is the setting of people, activities, information, rules, and relationships relevant to a problem. Scope states what an investigation, delivery, or trial will include and exclude. The domain is not necessarily identical to the system being built.

An invoice-search project may deliver only a lookup screen. Receiving staff, suppliers, approval rules, and receipt-record quality still affect whether that screen helps. Their work belongs in the problem analysis even when changing their software is outside the delivery scope.

Suppose the team evaluates whether the lookup screen helps. The evaluation should define the eligible cases and the boundary of the claimed benefit, and record dependencies outside the team’s control and who owns them. An eligible invoice that the screen fails to handle should remain in the evaluation; moving it out of scope after failure changes the result being measured.

The same word naming two different things

Scope is not only about what gets built. It is also about what a term means inside a given model, and the second kind is the one that survives into the data. “Customer” is the standard example: to a billing model a customer is the party an invoice is issued to, so a household with one account is one customer; to a marketing model a customer is a person who can be contacted, so the same household is three. Neither definition is wrong and neither is a superset of the other.

What makes a model usable is answering three questions explicitly for each of its main terms.

• What is in and what is out. Does this customer concept include prospects who never bought, canceled accounts, internal test accounts, resellers who buy on someone else’s behalf?
• What one row is. A person, an account, a household, a legal entity. This is the identifying unit, and disagreements about counts are often disagreements about it — though duplicates, missing records, late arrivals, and different observation times produce them too, so check those as well.
• Whose decisions it serves. The model that supports dunning and the model that supports campaign targeting have different owners, and the owner is who settles an edge case.

Connecting two such models is then a mapping, not a rename. Stating that the billing customer corresponds to a set of marketing contacts — with a rule for which one is primary, and an accepted treatment for the cases where no rule fits — is a piece of work someone owns. Assuming the two are the same because the column has the same name is how a report ends up counting households and calling them people, and the error is invisible because both numbers are correct for their own model.

Examples and calculations here are illustrative.

References:

• Martin Fowler: Bounded Context