The sales team has a spreadsheet explaining discounts. Operations has an email describing exceptions. The application contains a third interpretation written several years ago. When an unusual order arrives, people negotiate which version of the rule applies, then ask a developer to make a small change that turns out to affect several screens.
Domain modelling can help the team make those rules explicit. Its practical value is a shared description of the decisions the software must enforce, with clear places to implement and test them. The starting point is understanding the business language and its exceptions, rather than introducing a large collection of architectural patterns.
Follow one decision through the organisation
Select a recurring decision with visible consequences, such as whether an order can be approved or a reservation can be cancelled. Interview the people who make, review and support that decision. Ask for recent examples, including cases where the usual process did not apply.
For a hypothetical wholesaler, “approved order” may mean that sales accepted the price, that finance released credit or that the warehouse can dispatch. Those meanings are related but not interchangeable. Record who uses each meaning and what action it permits before choosing a single property name in the database.
Draw a short sequence of states and decisions. Include the information required at each point and the person or system responsible for supplying it. This often exposes missing concepts, such as a temporary hold or a reason for rejection, that were previously hidden inside free-text notes.
Distinguish rules from preferences and current habits
Ask what must remain true for the business operation to be valid. A confirmed order may require a valid customer and at least one order line. A screen's preferred sort order is a different kind of decision, even if both currently appear in the same application method.
Separate mandatory rules from policies that can change. A discount threshold might vary by agreement or effective date, while an already-issued transaction must preserve the terms under which it was created. Document the source and lifetime of each policy so later changes do not rewrite historical meaning accidentally.
Microsoft's domain-model guidance discusses enforcing invariants within the domain layer and distinguishes that responsibility from interface validation. Use that distinction to examine where the application currently permits invalid states. It does not require converting the system into microservices. Domain-model validation guidance.
Build an example set before designing abstractions
Write examples that make the rules testable. For order approval, include an ordinary order, an inactive customer, a changed price and a credit hold. Specify the expected decision and explanation. Where two business owners disagree, record the disagreement rather than hiding it in a flexible configuration option.
Use boundary examples deliberately. If an approval limit is inclusive, show the exact limit and values immediately above and below it. If time affects the rule, state the relevant timezone and effective date. These details are often where a seemingly clear business sentence becomes ambiguous code.
Keep the example set concise enough to review in a meeting. It should help the business recognise its own decisions. Once agreed, connect the examples to automated checks so future changes can show which intended behaviours remain intact and which policy decisions are being revised.
Give state changes meaningful operations
Consider whether the application exposes business actions or merely allows arbitrary property changes. An operation such as approving an order can validate its prerequisites and record a decision. A collection of unrelated field updates may allow combinations that nobody intended to represent a valid business state.
Design the operation's failure result as carefully as its success. “Customer account is on hold” helps the caller present a useful next step. A generic exception leaves the interface or integration to guess what happened. Keep operational diagnostics available without making internal implementation details the user's only explanation.
Apply the same rule across entry points. A browser screen, import job and API client should not each carry an independent version of order approval. Establish a shared application path or an explicitly equivalent enforcement mechanism, then verify the important differences in authentication and input handling around it.
Define the boundary of a consistent change
Some information must change together to preserve a business rule. Other information can be updated later with an explicit delay. Determine that boundary from the decision being made rather than assuming every related table belongs in one large operation.
For the wholesaler, confirming an order and preserving its agreed line prices may need one coherent transaction. Updating an analytical summary could happen separately if its freshness is clear. Document what users can rely on immediately and what is still being processed after the main action succeeds.
Consider concurrent changes. If finance adds a credit hold while sales approves an order, the system needs a defined resolution. A domain model that looks clear in a single-user demonstration still requires appropriate database and concurrency behaviour. Use conflict handling to connect the model to real multi-user operation.
Introduce the model through a small change
Choose one rule that is already due for maintenance. Identify its current entry points, capture representative behaviour and introduce a clearer operation around that slice. Keep unrelated parts of the application working while the team gains evidence about the new structure.
Review whether the change improves understanding. Can a developer find where the rule lives? Can the business owner explain the examples? Can support identify why an action was rejected? If the new design mainly adds terminology without improving these tasks, simplify it before expanding the approach.
Worktechlabs can help clarify and implement rules in ERP and business software. Pair domain modelling with targeted tests and gradual modernisation so the team improves a working system through verifiable steps. The useful result is a rule that remains understandable when the original developer or spreadsheet author is no longer available to explain it.
Official sources and further reading
- Microsoft: domain-model validation — invariants and validation responsibilities.
- Microsoft: handling concurrency conflicts in EF Core — persistence behaviour relevant to competing business changes.
