You can use this delivery method to deploy and evolve an MDriven application in an enterprise team while keeping business rules, release decisions, and operational feedback connected.
Treat the MDriven model as the shared description of the business system. Define classes for the data, associations for aggregated information, and state machines for the rules that govern data changes. Define OCL (Object Constraint Language) expressions for declarative business rules, and use a ViewModel to shape data for a specific use case without changing the domain model.
For example, an order-approval application can model Order, Approval, and User as classes; associate an order with its approvals; and use a state machine to represent draft, submitted, and approved orders. Create a ViewModel for the approver's work list rather than adding work-list-specific properties to Order.
Keep the model available to domain experts and developers throughout delivery. This makes the business logic a reusable, inspectable artifact rather than knowledge held by individual developers.
Deliver in small, verified increments
Use an iterative delivery cycle in which users validate the system against the current business need, then refine the model and views from their feedback.
- Model one coherent business capability, such as submitting and approving an order.
- Create objects that follow the model and use them to check the classes, associations, and state changes with domain users.
- Refine the ViewModel and views for the users who perform that capability.
- Deliver the change through a repeatable deployment process.
- Review user feedback and operational evidence before selecting the next refinement.
Keep each release focused. A small change to the approval work list is easier to understand and diagnose than a release that changes approval rules, user navigation, and unrelated business areas at the same time.
Make deployment repeatable
Use Deployment guidance to select the hosting approach that matches your environment: on-premises or cloud, Windows or Linux, IIS, Azure, Docker, or another documented option. Use CI/CD (continuous integration and continuous deployment) to make the deployment process repeatable rather than depending on manual, individual knowledge.
Use a release strategy appropriate to the change:
| Situation | Delivery approach | Example |
|---|---|---|
| A change must be introduced broadly after verification | Use the stable-build path documented for CI/CD. | Deliver an approved change to the order state machine with the normal release. |
| A change needs controlled exposure before broader use | Use the documented canary-build approach. | Make a revised approver ViewModel available to a limited user group, then use feedback before wider delivery. |
| A view issue needs attention between larger releases | Keep the view change under version control and deliver it through the repository-based process. | Correct a label or layout in an approval view without editing an XML file directly on the server. |
Do not edit deployed XML files directly on a server. Keep view changes in the Git repository so the version history and the delivered change remain aligned.
Separate application responsibilities in IIS deployments
When deploying MDrivenServer and Turnkey Core on IIS, create separate application pools for MDrivenServer and Turnkey to improve isolation. Follow the IIS deployment guide for the required connection configuration and model upload steps.
Turnkey deployment has two parts: Turnkey and MDrivenServer. Deploy them in the documented sequence, and investigate the MDrivenServer deployment package when the portal reports an error during the MDrivenServer step. Use Troubleshoot Turnkey Deployment for this failure pattern.
Plan for scale and diagnosis
Make scaling and operational diagnosis part of the delivery plan, not a post-release activity. Review the documented load-balancing considerations for Turnkey and MDrivenServer when the application must handle increased load.
Collect information that helps you understand how the delivered system is used. Navigation and action logging can show which views users open, which actions they use, how often they use them, and how those views perform. For example, if approvers rarely open a new work-list view, review the ViewModel and navigation with the users before expanding the rollout.
When an IIS-hosted application fails to start, check database connection strings and network connectivity for database connection errors.
Keep feature delivery under model control
Decouple delivery of a change from enabling it for every user when the business need requires controlled exposure. Model a setting on the user, such as a Boolean attribute that indicates whether a user can access a capability, and check that setting in the enable expression for actions that affect the capability.
For example, add an attribute that controls access to a revised approval action. Enable the action only for the selected approver group while the team verifies the new process. Keep this control in the information model so the rule is visible with the rest of the business system.
Delivery checklist
Before each enterprise deployment, confirm the following:
- The model describes the changed business data, relationships, rules, and lifecycle states.
- Domain users have reviewed the changed capability with representative objects and views.
- The ViewModel supports the intended use case without distorting the domain model.
- The deployment path is repeatable through the selected CI/CD process.
- The rollout choice is explicit: stable delivery, canary delivery, or a controlled feature exposure.
- View changes are versioned in the Git repository and are not edited directly on the server.
- The team knows which logs and usage evidence it will review after delivery.
- Scaling and load-balancing requirements for Turnkey and MDrivenServer have been considered when applicable.