The rule in two places
A mobile screen and the case service both check a transfer request. If a rule change reaches only one of them, the screen may show a transfer as accepted while the service rejects it. The design must identify where the rule is defined and how its implementations stay consistent.
Software design describes how components fulfil the responsibilities assigned to a system. It connects business rules, algorithms, state, concurrency and failure behaviour to code that can be understood, checked and changed. Conceptual, logical and physical views apply across every architecture aspect.
The systems contract defines accepted case transfer. This section examines the components that could implement it, including the checks between a proposed result and a permitted state change.
The useful questions
| Concern | Question for the case service |
|---|---|
| Responsibility | Which component owns the transfer rule, and which coordinates the operation? |
| Input and output | What information does each function need, and what does its result establish? |
| State | Which facts change together, and what must remain true after every accepted operation? |
| Dependencies | Can the rule be checked without a screen, database or model provider? |
| Concurrency | What happens if the case changes between reading it and saving the result? |
| Failure | Is an invalid proposal, conflicting update or unavailable dependency handled differently? |
| Change | Which code, prompts, definitions and checks must move together when a rule changes? |
Components and contracts
A component is a part of the software with a defined responsibility and an interface through which other parts use it. It might be a module, library, class or set of functions. Its name alone does not require a separate service or deployment.
Separate the transfer decision from the mechanisms that obtain requests and store accepted changes. A mobile or browser client can offer early feedback, but the responsible service enforces acceptance. An adapter translates a particular interface into the application’s input; a storage adapter implements the agreed persistence operations. Whether storage is local or supplied as a managed service, its implementation must preserve the agreed atomic changes and failure behaviour. The adapter contracts make it possible to replace or check each dependency separately.
The separation has a cost: extra interfaces and conversions need maintaining. Use it where the rule, dependency or likely change warrants it. The comparison examines several ways of making those decisions explicit.
Rules and state
Write the rule in terms of business facts. For example, the receiver must be the person named in a current offer and must have authority to accept it. Name the invariant—the condition that must remain true—such as one current owner for each active case.
A decision function can inspect supplied facts and return a proposed transition without changing the stored case. The operation that applies the transition must check that those facts are still current. A passing rule check on an old copy does not make a later write safe. Put the version check and related updates within one atomic operation, so all take effect together or none do.
State includes pending work and recorded failures as well as successful results. Define who may retry, what a retry means, and which result lets the caller continue. The worked example separates a repeat of an accepted operation from a new request based on stale information.
Representing the decision
Choose a representation that the people maintaining the rule can understand. A small function may express a calculation clearly; a decision table may make combinations of conditions easier to review; an explicit state model can show which transitions are allowed. A domain-specific language needs defined meaning, diagnostics, versioning and an owner for its execution tools.
Language choice also affects numeric behaviour, memory and resource ownership, libraries, interoperability and support. Record assumptions that callers rely on. Replacing a language or compiler is a behaviour change to check, even when the visible rule appears unchanged.
A step using artificial intelligence (AI) also needs an input and output contract. Its output may vary or contain unsupported statements. Define what is checked mechanically, what a person reviews and what can proceed to another prompt or tool. Keep permission to change accepted business facts in the application’s controls.
Checks and change
Use small rule examples to expose ambiguity, then check the real storage and interface behaviour that an isolated function cannot exercise. Include invalid inputs, concurrent updates and interrupted execution. For a model step, inspect both the resulting content and any actions it attempted; plausible prose alone does not establish correct behaviour.
When a rule changes, retain its reason, version and affected consumers. Review stored and pending work as well as new requests. Generated code and prompts need the same review of meaning, dependencies and failure behaviour as other changes. Faster drafting can increase the work waiting for acceptance.
Speed and quality
Observe time to locate a rule, make an accepted change and investigate a failed operation. Record correction effort, escaped defects, test maintenance and support work. Compare an abstraction’s cost with the changes it actually makes easier. Useful life becomes clearer as the software survives changes of rules, maintainers and dependencies.
Security develops enforcement, restricted tool authority and checks against misuse of the software’s contracts.
Methodology configuration
Your method may use modules, objects, services, rules, use-case realisations or features. Map each to its responsibility and retained contracts. Place the cycles, example and records in the design and review steps you already use. See Methodology configuration.