You can secure business knowledge over time by keeping the model definition under version control, retaining database backups, and using MDrivenServer History for temporal data investigation.
Keep the knowledge that defines the system
Your system's gist is the business knowledge expressed in its model: the concepts, relationships, and rules that describe how your organization works. This is distinct from modernity, the technology used to run and present the system.
For example, a Customer class, its association to Order, and an order-approval rule express business knowledge. A change from one web technology to another should not require you to recreate that knowledge.
Keep the model as an actively maintained representation of how the business works. This gives developers and business stakeholders a structured place to inspect and change the knowledge rather than leaving it distributed across application code and documents.
Use the right retention mechanism
No single mechanism preserves every kind of history. Use each mechanism for the question it can answer.
| Need | Use | Example |
|---|---|---|
| Know which model definition was valid at a past time | GIT, or another repository for code and definitions | You need to see when Customer.LegacyNumber was removed and what rules used it before removal.
|
| Restore the complete data and definition from a past point in time | Database backups and backup-retention settings | You need a complete snapshot of the production database and the definition that accompanied it at month end. |
| Investigate how current data reached its current state | MDrivenServer History database | A support user needs to browse changes to an order status and determine when it changed from Pending to Approved.
|
Understand the limit of history views
MDrivenServer History views past data through today's model definition. It is a history of data, not a history of definitions.
If you add a new attribute today, history cannot show values for that attribute before the attribute existed. For example, if you add Order.ApprovalReason on 1 July, there is no approval-reason data to show for changes recorded in June.
If you remove a definition, historical data that requires that definition can no longer be represented in the current definition. Removing Order.LegacyStatus, for example, removes the way to represent its historic values over time in the history view.
Keep the model in GIT when you need to understand historic definitions. Keep retained backups when you need full historic snapshots of both data and definition.
Use MDrivenServer History for operational investigation
A MDrivenServer History database is a manageable middle ground for systems whose definitions are mostly stable. It supports temporal browsing of recent changes at full event resolution, unlike backups that contain snapshots only.
Use it to answer questions such as:
- Why is this customer record in its current state?
- How often has an order changed status?
- How has the number of active subscriptions grown over time?
- Which change introduced the data condition reported by support?
This supports business analysis, support work, and debugging without repeatedly restoring old backups. Plan for the stated limitation: changes that remove old definitions can cause historic data loss in the current history representation.
Keep documentation connected to the model
Prefer knowledge that is maintained with the model over separate documentation that people must remember to update. When a generated artifact refers to a model attribute, the model can expose that usage when someone inspects the attribute.
For example, generate a static HTML product page from model data and retain the generated document when you need a historic record. Model usage information can help a maintainer see that an attribute is used by the static HTML generation before they remove it. See the static HTML and cache invalidation walkthrough.
Protect knowledge while exposing only what users need
Knowledge retention and information security are related but separate concerns. Retain the business knowledge in the model, then expose only the approved data and actions for each authenticated user.
A ViewModel defines a perspective on information for a specific need. For example, an order clerk's ViewModel can expose order status and an Approve action without exposing all customer records or the implementation of the approval logic. Keep access-control logic on the server; clients should request actions rather than enforce the rules themselves.
See Documentation:High or low exposure to risk and Training:Information security for the exposure and access-control considerations.